Development page for PatternSkin

Refactored to highlight outstanding work -- CrawfordCurrie 08 Jul 2004

Executive summary:

1. Present the user a link/button with "Create new topic". See CreateNewTopic.
2. In Edit, use Koala's savemulti
3. In Attach, add a button "Move to Trash"
   • The page "Move attachment" does not show the Trash Web
4. In More, add 2 links/buttons: "Quick delete" and "Custom delete"
   • Quick delete moves the topic to Trash Web
   • Custom delete is similar to current "Move", except there are no locations to choose from
   • Provide a link to earlier deleted topics
   • Preferably, present a feedback page after delete
5. In More, add a "Rename topic" link/button
   • Page is similar to current "Move", except user can only change the topic's title
6. In More, see if 'select parent' really needs a topic edit

Examples:

• the Diemen Repository
• Flash SIG (simpler left menu)

See also:

• PatternSkin -- dummy page because the skin is not released
• PatternSkinDev

The Pattern skin was never released as a skin. I created it for my own twiki installation (the Diemen Repository) because I was not satisfied with the usability of the default skin, and also other skins did not appeal to me.

Then I received really positive reactions about my 'skin'. People asking me when I was going to release it. That was the main reason I set up this page, to share my work, and to bring it further. I am now a member of the CoreTeam working on the usability of the default distribution.

-- ArthurClemens - 30 Aug 2003

On this page:

Workflow

The general working order is:

1. Write flow diagrams to order actions (buttons, links) to show the logic between pages. Tries to be so complete as possible - error pages are also included.
2. Design diagrammatic page designs (Page diagrams, see also attached example) to order the logic on the page. A number of pages in (1) can probably share one page design. Re-view step 1.
3. Design/write templates (as in .tmpl), a bit of Photoshopping.
4. Create CSS along the way, refactoring in each step.

Currently:

• Flow diagrams
  • Done:
    • View (lacks a couple of error pages)
    • Edit
    • Attach
    • New topic
    • More (lacks a couple of error pages)
  • To do:
    • Combined Edit and Attach (eventually, no priority for now)

Comments on the flows are welcome.
All changes to pages and new pages/templates are colored green
See for explanation of flow diagrams: http://www.jjg.net/ia/visvocab/

• Page diagrams
  • to do...
• Refactoring of templates:
  • to do...
• Documenting and producing of patch files
  • Done:
    • Sidebar navigation with parent-children patch file
    • Formatted TOC patch file
  • To do:
    • Underscore wiki_word_links
    • ...
• Refactoring of style sheet
  • to do...

Status of Patches

List of patches of PatternSkin, diffed against TWiki20030201:

• Sidebar navigation with parent-children patch file
• Formatted TOC patch file.

Proposed changes

Changes that I propose or that are raised by others in other topics to improve usability, and that I would like to see in the default TWiki configuration.

General

• See UnderscoreWikiWords: Add underscore_wikiword_links in addition to traditonal WikiWords. Make the use of underscores an option: Many programmers are use underscores in names, so code descriptions in a TWiki topic would show unexpected links. This is not an issue for non-programmers. Possibly a configuration switch? (TopicSaveErrorWithTopicsContainingSpace)
  • SCHEDULED FOR DAKAAR see DakarRelease

Search

• Make the Go box a search box. See for instance KOALAwiki and GoIsSearch for implementations. Should be coupled with KeywordSearchWithImplicitAnd. Could be integrated with dropdown box to expand search (see KOALAwiki).
• Advanced search topic contains too many options.
  • Page diagram forthcoming.

Edit

See also attached flow for Edit.

• Implement SaveMulti to allow for direct saving when editing. See SavemultiCgiScript
• Create a template/topic to "Create new topic" (instead of entering the wrong wiki word in the Go box). See NewTopicTemplate and DynamicEditTopicTemplate.
• Create a visible link in the view template so everyone knows where to go to create a topic (without having to read the manual).

Attach

See also attached flow for Attach.

• Integrate Attach with Edit on one screen: Edit at the top, Attach at the bottom. Attaching is almost never a single operation - almost always you need to change the topic text afterwards. See discussion on this page.
• Bug: Uploading a different filename should not create a new file. Work in progress: UpdateAttachmentsDontWorkAsExpected.
• Separate "Delete", "Move" and "Rename" to separate templates; see TrashButton, MoveAttachment
• Change "action" link to "manage". This makes it clear what the button does. Done: AttachmentActionLinkBadName, BetterAttachmentTableForCairoRelease

More

• See BetterMore: Create a Trash button on the "More edit options" page. See TrashButton. Create a link to the Trash web called "View deleted pages" (see DeleteTopicShouldNotFollowIt).

• • Have to read TrashCanWeb yet for more details.
• see if 'select parent' really needs a topic edit (SaveContentWithoutEdit)

Discussion

Thread mode discussion. Conclusions will be added to #Raised_issues

At my work, when we start designing a website, we actually always start with an Interaction Design (after we have a basic concept). This ID documents the flow of pages, the navigation, the functionalities of each page, the kind of copy that should be there, the Content Management System templates. When the main draft is dry, we consult with programmers which ideas are feasible, and which will be too expensive. We also have some presentations to our client.
When the Interaction Design document is finished, this is the leading document for programmers for writing a Functional Design and a Technical Design, and for designers for their graphical design. The ID can change if certain implementation issues arise.

I think that for developing a new out-of-the-box interface, we should start with an Interaction Design.

-- ArthurClemens - 29 May 2003

Your skin is exceptionally good from the usability perspective. Yes, we are interested in getting hold of your skin and code changes that makes this possible.

I renamed this topic from PatternSkinDev. This topic here should focus on code changes needed. Skin specific changes should go to PatternSkinDev in the Plugins web.

-- PeterThoeny - 30 May 2003

So how do we go about beginning the Interaction Design phase? Can it be conducted effectively via the written word (e.g. here, email) or do we need to try and arrange some IRC sessions or phone calls? I have a few things to say about the new design, whatever it looks like, but don't want to dump my ideas on the table prematurely and fracture the discussion unnecessarily. I guess this all adds up to "I'm in. What do I do?" (^_^)

-- MattWilkie - 30 May 2003

Glad you're with the party. But, don't run so fast! An interaction design for a middle sized site can take 2 till 3 weeks, fulltime. So...
To set up this project in a structured way ( I am saying to myself) let's take some steps back to try to enumerate what should be in there. Basically I am talking about pages as sequential steps in processes, not templates per se. Templates are already implementation. Some templates should be broken up (for instance, why are Rename, Move and Delete on one page? Probably because the code is similar, but I would never combine these actions...), some can be gotten rid of (maybe, see MoreCommonHeaderFooterTemplate) or simply better structured in code (so we also have site owner / skin developer usability). Or templates added, like I would like with NewTopicTemplate.

Then we have the challenge to make all elements on the page change appearance (to not use the word 'skinnable'), at least in colors, fonts, but also in amount of complexity presented to the users - so some parts have to be switched on or off. And it should be flexible (pun intended).

This is a good time to decide about implementing core functionalities that have been laying around for some time, like SavemultiCgiScript. That seems like a good one to me, for example.

I have not been involved in open source before, so I am not sure how to do the interaction design this way. Best will be probably to use the wiki way, and for me to sketch it all down. These sketches will be really blocky and gray For you who are not familiar with an Interaction Design document, I will attach an (older) example page to this page. Why can't I attach a file while I am editing? Grrr.

In this process, I will take on the voice of the users. Of course, anyone that is in contact with real users in his/her work can also bring forward user's votes, or just bring in something from your own experience. In fact, I do need more information than I have now. I need to know in what environments the TWikis (or other wikis) are used. I read somewhere that it is used for project management? Fine. What kind of things did you change, and what does not work out?

On a side note: one thing I learn from Usability, is to be careful with relying on what users say about a site. What is important is what they do. See for an interesting read: Testing the Three-Click Rule.

In all this will be an iterative process. So please do bring in your comments and we can discuss them or save them for later.

-- ArthurClemens - 30 May 2003

Convenient Edit-Design

Attach integrated with Edit

This seems like a good time[0] to ask: is there any good reason for attach to be a topic-action in view mode? In thinking about my behaviour, I realised I cannot recall a single occasion where I've attached a file without also editing the topic.

I see two benefits to attach being an edit mode topic-action: 1) simplifies the already link-heavy view mode, 2) combines two activities into a single process, making the whole editing procedure just that little bit smoother.

If attach were to moved to the edit page, it should be the attach page, not the link-to-the-attach page or the only thing we've done is add another step.

To not freak long time twiki users out there could be an indefinate phase in time where attach is available from both pages.

[0] I know Arthur is just charting out the existing territory first. I don't expect action or even discussion on this right away. I just want the idea rattling around for when the time is right.

-- MattWilkie - 06 Jul 2003

I also wanted to decrease number of links - my solution (In SimpleSkin) was to move Attach to More. So I have only Edit History Print More actions. IMHO edit should be edit. I'll prefer even "change form" to move to More.

-- PeterMasiar - 06 Jul 2003

I agree that it currently is a pain in the ass to attach a doc while you are editing: first preview, save, attach, edit again to put the attachment at the right place. So I welcome the idea of moving it to the edit page. To combine the two templates makes sense, it would be a good improvement. I will put it in a flow diagram.

What technical issues could be hidden here?

-- ArthurClemens - 29 Jul 2003

Not sure whether this is the right place to admit this, but I have been sitting on a reasonably functional but unreleased JavaPasteAddOn (better version sitting in CVS) that allows you to paste attachments into a panel on the page. A signed Java applet, it finds the files named on the clipboard and calls upload.

It needs testing, and would need fallback for non-java browser people, but I wanted to mention it for the design flow.

-- MartinCleaver - 29 Jul 2003

I like the idea of adding the ability to attach files in the edit template. This is actually a relatively common practice on web based email systems. Typically on the bottom of the form they have 3-4 "Attach files" buttons which allows one to attach up to 4 different files all at the same time.

But I think this should be in addition to the already available option of just attaching a file. I wouldnt want to change the flow such that you had to edit the topic in order to attach to it.

Separately, if people think there are too many buttons available on the view pages, we should consider some javascript menus similar to what is available on the tigerskin. That is a very nice way of keeping things visually simplistic until someone needs to access the functionality.

Just my $0.02

-- JohnCavanaugh - 13 Aug 2003

John, that is considered bad design by some usability experts. I suggest you read the nice pages from Vincent Flanders named http://webpagesthatsuck.com :-), especially the "Mystery Meat Navigation"

-- ColasNahaboo - 13 Aug 2003

I agree. Not done. Users decide what they are going click before they move the mouse, so if it is not visible, it won't be clicked. If it is hidden, they need to remember.

Don't let people guess what they can do with the page. A lot of people that I would like to see using TWiki are not familiar with Wiki concepts. They will use it infrequently, so they will forget what I tell them. They need to have it very much in front of them that they can edit the page, and preferably that they can attach documents.

There is also a business concept behind this. Well sort of. If your TWiki site was a business, Edit and Attach would be its Unique Selling Points. It is what I use when I am advocating my TWiki. I begin telling "This is a website, where anyone can edit the pages", and I show them the 'Edit this page' button.

I wouldnt want to change the flow such that you had to edit the topic in order to attach to it. There wouldn't be a difference in efficiency, as going to the attach page takes as long as going to the edit page... It's only that you have to know you can attach by using Edit. Or just leave the Attach button, and link it to the Edit page.

-- ArthurClemens - 13 Aug 2003

Colas - Which comment exactly were you referring to?? The one about having dual methods for attaching, or the one about having the javascript menu for "More"?? - The javascript one - CN

Arthur - Its a reasonable argument you put forth on having to go to the attach page taking as much time. Probably my only concern is what happens to the edited text during an attachment. Unless you are including a link in the text itself, the topic shouldnt change, just the meta-data, what does that do to the "versioning" of the topic??

Im probably breaking another usability standard (I blame on using such bad software over the years that I have been conditioned to think "bad") but perhaps the edit/attach script should be a combo and the page should have 2 tabs on it, one for editing the other for attaching. That way if someone wants an attach button it could automatically take them to the combo page with the attach tab preselected, vice-versa for an edit button. Might introduce some complexity, but seems to be a way to keep things separate but easily accessable.

In fact the more I think about this, the more I like it. Often when I do attach files, I select the "include link" at bottom. After the file is attached I then of course have to go and edit the topic to move the link to somewhere that makes more sense than the default at the bottom. A two tab interface would allow you to attach a file, switch over to the edit tab (which on the click to the edit tab uploaded the file & appended the link to the bottom) and move the link to where I want it to be.

Another $0.02...

-- JohnCavanaugh - 13 Aug 2003

About this tab idea: I think this can be enhanced. Why would you need two pages (2 tabs), if you can do it on one? You can have it all on one page: first the edit box and the usual buttons, form etc; below the attach part. At the top of the page you can have an inpage link going to the attach part. And from the topic page you can link directly to the anchor link. The advantage of this is that any attachment code that is pasted into the text can directly be edited (after a page reload). Scrolling up and down is quicker than loading a new page (well unless you use DHTML tabs of course).

-- ArthurClemens - 13 Aug 2003

That would work fine as well. What about the ability to attach more than one file?? I was thinking maybe 3-4??

-- JohnCavanaugh - 13 Aug 2003

BetterSaveBehaviour

-- AndreUlrich - 09 Feb 2004

When gets this thing published?

Where does one get the code for PatternSkin?? I see a diff but no place to get the actual download. Im interested in installing it and playing around (modifying it etc).

-- JohnCavanaugh - 20 Aug 2003

Well, its called a skin but it is not packaged as such. It is also quite rough (code-wise), so definitely not apt for public use. What I try on this page is to document the main principles and at the same time make decisions that can benefit twiki as a whole. So discussions on this page will have impact on twiki.

-- ArthurClemens - 20 Aug 2003

Oh, c'mon, Arthur, post whatcha got! It's a great skin. Label the code/templates as "a work in progress" and stop being such a control freak. You never know, someone out here might pick up the ball and help you clean up the skin. Isn't that the beauty of a wiki (when it works), anyway?

-- TomKagan - 21 Aug 2003

But it does mean I need to have my patch files sorted out. That is, create them first. Without the code changes a lot does not work. -- ArthurClemens - 21 Aug 2003

I have started to catalogue patches first. -- ArthurClemens - 29 Aug 2003

The diagrams look good to me, though I confess I'm not very good with flow charts. I usually have to actually try the methods before I see problems. : ) Two small comments:

1. the view chart has a "No perm. to create web" box which I think belongs in a diagram not created yet (sys admin tools or somesuch; the same place things like ?cmd=repRev would go).
   • yes, I did not know where to put it. Looks like I can remove it there. -- AC
2. for Flow_More, left most column, are 'Advanced options' and 'More' really supposed to be seperate steps?
   • Ehm, no. 'Advanced options' is the link label, and 'More' is the name of the flow area because the template is already named more. -- AC

First Arthur, it is really helpful to have these diagrams!

I have some comments about the view chart. In my opinion users should not be overwhelmed with functions. A storm of functions leads rather to confusion than it does help the user to find what they want.

• There are a lot of possible links that are available at some time in a topic view. It does not mean they need to be present at the same time. Some links are part of the view template, others are links in the topic text but link to another template. -- AC - 27 Sep 2003

Especially the view-template should be consist of a clear set of functions and not offer all functions available. Functions like e.g. "last diff" "previous version", "raw text"(!) or "RSS" are either seldom called function or slightly modified versions of another function e.g. of "Topic revisions".

• Once I have enough feedback I will continue on page diagrams, to find out which links should be placed where. Seldom used functions obviously move to the bottom of the page, as it is now on twiki.org. Seldom used does not mean never used, and we must be careful not to exclude frequent users. (We must be careful not to fighten beginning users either). RSS is a link that you will put on the homepage, or possibly on other pages in the form of an XML icon as you find on many weblogs. Raw text is very handy if you put code examples in the topic text. -- AC - 27 Sep 2003
  • Maybe I mixed flow- and page-diagramms, sorry You said, that RSS is rather a link within a page, that's also my opinion. I just wondered what it has to do in the view chart, as it is a separate function. -- AndreUlrich - 27 Sep 2003
  • Functions that are obviously do the same thing e.g. "last diff" "previous version" are a modified version of "Topic revisions" and should be seen as one function or template. -- AndreUlrich - 27 Sep 2003
  • Ok, many different user-groups have to be considered by the design. Maybe there should be a variable to turn on "advanced mode" to show all the function I never used in 2 years of TWiki -- AndreUlrich - 27 Sep 2003

Classify the functions in site-/web-functions and group them together would raise usability too.

• Not sure what you mean by that. -- AC - 27 Sep 2003
  • This was more directed to the page-diagramms. E.g. our skin groups site-/web-functions to guaranty a constant navigation experience.

I can't find the function "topic index" in the view chart. Although this thing is almost unuseable within big webs, this function should be available somewhere?

• You are right. But the index is not a template, its a topic. I will put the link in the page diagram. -- AC - 27 Sep 2003
  • Ok, but "last diff" "previous version", "raw text" are neither own templates. In my opinion functions that don't need a special template should also be considered, as it provide a more general view. For example "Changes" could also be realized through a normal search. -- AndreUlrich - 27 Sep 2003

The "ref-by" has no box, so it stands only for a search parameter within the view chart?

• This one is at the left, the lower line with label 'Pages that link ("ref by" / like)' -- AC - 27 Sep 2003
  • Yes, I saw this one. What make me confusing is that it's not within a box like the other functions. Of course this may also be a "non template"-function and therefore without a box. -- AndreUlrich - 27 Sep 2003

What about parent-relations? Are they integrated in the "pages that link"-item?

• No, these are just links to other topics, and will be covered in the page diagram. -- AC - 27 Sep 2003

Ok, all I wanted to say that it should be well deliberate which functions belong to a view.

• I will work this out. Thanks for the feedback. -- AC - 27 Sep 2003

Obviously I'm get confused by the flow presentation, hopefully it get's better with the page-diagramms

• I've made some changed to Flow_View. Related functions are now grouped. Page links are indicated so. -- AC - 27 Sep 2003

-- AndreUlrich - 27 Sep 2003
-- ArthurClemens - 27 Sep 2003

The PatternSkin can be found in TWikiCoreSvn, and the TwikiPluginsCvs.

-- SvenDowideit - 27 Jun 2004

NO LONGER SCHEDULED FOR CAIRO as individual parts have been abstracted out into patches and other topics individually scheduled for Cairo, as it was impossible to track in this form.

-- CrawfordCurrie - 08 Jul 2004

I'm making a few changes to the templates in DEVELOP - these can be tracked in DakarSkinSimplification

-- SvenDowideit - 08 Jan 2005

moved bug fix report for SVN tracking to PatternSkinDev -- TW