TWiki.org skin

Development and discussion topic for the new (2008) twiki.org skin.

Why do we need a new layout for twiki.org?

This site uses pattern skin, the default skin that comes with the distribution. As anyone who has used TWiki for a client will know, changes need to be made to make it fit to the specific environment.

With WebPageAudience we have developed our target audience for the website. These are users that may be interested in downloading/installing TWiki for their company. Or they may be new developers (note: not programmers per se) that want to contribute.

So these users are not the typical current developers. These new users need to read (scan) a lot of information without having background (or patience) to support them.

What do these users need to succeed?

1. A more read-oriented website than a write-oriented
2. A sense of what the site has to offer. A simpler navigation with less options to choose (so they will not get confused by the myriad links in the left bar)
3. Clear overview pages that can guide them to a specific piece of information
4. Short bite-size pieces of information to print and send

For specific information needs, see WebPageAudience.

These information needs may conflict with the needs of developers. If we develop a new look and feel for our target audience, we may hamper usability of current developers. For instance, developers may need to have quick access to often visited pages. Luckily, TWiki has the ability to set the preferred skin in the user's topic. Every developer may set his preferred look 'back' to pattern skin if desired.

What are the proposed changes?

1. Use a horizontal top navigation for webs
2. Use a horizontal navigation for the main entrance topics for each web
3. Optionally use a folding out menu to quickly access deeper pages (need to be developed)
4. Make the breadcrumb navigation more visible
5. For each topic create a distinct introduction text
6. Use blocks to highlight sub topics or to show illustrations
7. Make use of graphics to help scanning the page
8. Use the page to write page navigation. So instead of a topic name we can write a human readable title plus a summary line.
9. ... (add here)

Contributors: ArthurClemens

Design proposals

• proposal 001 (08 Sep 2008)
• Updated design with example usage, a quote and different topic actions (plus colors) proposal 002 (21 Sep 2008)

-- ArthurClemens - 21 Sep 2008

Discussion

Yes, I think we should do more to orient the TWikiOrgSkin look and feel towards the massive majority usergroup - those that turn up to search and to read. The current Skins are way too biased towards editors.

-- SvenDowideit - 10 Sep 2008

I like the designs a lot. But please erase the "Jump" box altogether. It is a severe usability problem and does not help at all. This solution from Wikipedia would be much better:

image removed from here

• Thanks Martin. I am also not in favor of 2 input fields, and this is a long outstanding discussion that has not resulted yet in a concrete feature request: ReplaceGoBoxBySearchBox. -- ArthurClemens - 23 Sep 2008

-- MartinSeibert - 22 Sep 2008

Arthur, proposal 002 is great! I like it very much. How can we check it out in action?

-- MichaelDaum - 26 Sep 2008

Thanks. It depends on what we want to get out of it. I can make a clickable prototype, or start immediately with a new skin. What would you like to test?

-- ArthurClemens - 26 Sep 2008

I'd like to test it on different content, eg. normal twiki-ing. So it makes sense to prep a skin/theme right away. I can help on browser compatibility if you like.

-- MichaelDaum - 26 Sep 2008

Perhaps you could do a simple prototype by creating only a cover for the view script in a single tmpl file, so we can test it.

-- RafaelAlvarez - 26 Sep 2008

I know that much discussion on the topic has already occurred. But in my company's TWiki—where many are still intimidated by editing—no one is confused about the use of the Jump and Search boxes. In fact, most users use the Jump box more often than Search and use the Jump box as the preferred method to create new topics.

-- DavidWolfe - 26 Sep 2008

Always good to hear counter arguments from eyewitness reports...

-- ArthurClemens - 26 Sep 2008

Isn't the real jumpbox the one starting with http://...

-- MichaelDaum - 26 Sep 2008

The URL bar is the very nerdy version of the Jump box. I'd need to append ?topic=TWiki.plugin in the URL bar to get the list of all plugins. A 10 on Kenneth's excellent NerdoMeter. I know many users in large TWiki deployments who could not live without the functionality the Jump box offers.

-- PeterThoeny - 12 Oct 2008

Arthur, excellent work! Nice look for landing pages.

Question: Do you propose to go away with the sidebar for all twiki.org topics or just the landing pages? Personally I'd love to see the sidebar on normal collaboration topics.

-- PeterThoeny - 12 Oct 2008

Let's put aside the jumpbox discussion ("don't touch my jumpbox ").

Carlo, our usability expert, already pointed us into the right direction on that issue long time ago. Martin made a good suggestion as well.

Anyway, how can we make this skin reality? What are the next steps? How can I help?

-- MichaelDaum - 13 Oct 2008

Coming Friday I am leaving for a one-week holiday, so then (in the evenings) I will have time to do the skin.

-- ArthurClemens - 13 Oct 2008

I haven't been following this discussion closely, so this might have already been discussed.

It may not be clear to a newcomer, looking at the header bar for the first time, the difference between Apps and Extensions. Also Support and Community. I would suggest a tooltip with a short description of what to expect.

-- PankajPant - 23 Oct 2008

Good remark. I feel the same. The term "Apps" is too geeky. The fully expanded "Applications" is too generic to mean anything. Most people looking for a way to augment their installation will end up looking at "Extensions". Not sure how to direct people to "Apps".

-- MichaelDaum - 23 Oct 2008

Right now, it is structured that way (Apps, Extensions) because we as experts think that way. For non-experts just "Extensions" is definitly easier. We can differentiate on a lower lever if necessary.

-- CarloSchulz - 23 Oct 2008

Carlo is right. Back in history Martin suggested extension as umbrella term for plugins, skins, contribs and add-ons why not apps too, as they all extend the value of TWiki. So I suggest to create a new Ext web, possibly with sub-webs Plugin, Skin, Contrib, Addon and App (be aware to implement a proper display name mechanism with the full names: "Extensions" are "Plugins", "Skins", "Add-Ons", "Contribs" and "Applications"). We would keep the Plugins web for historic reasons, but could start over from scratch as well.

-- FranzJosefGigler - 23 Oct 2008

IMO, Extensions are things that extends TWiki as a platform, and Applications are things that use the platform services.

Thus, TWikiApplications are not extension of TWiki, in the sense that Windows applications are not extensions of Windows.

-- RafaelAlvarez - 23 Oct 2008

While Raf's right, it feels to me like a pretty un-useful hairsplitting. Sepecially as there are many Contribs that from a user perspective provides an application, but from a techy perspective extends TWiki - Action tracker for eg - users don't know or care how its done.

on the piccies above - I think the orange is way too in your face.

-- SvenDowideit - 23 Oct 2008

The applications web I want to drive has nothing to do with extensions. It is plain wrong to mix up the little TML based TWiki applications that I want to create an end user community around and complex programming contributions like plugins, skins etc. I have the feeling some of you see the Apps web as a place where you will put some of those huge applications that you have built up of plugins, skin mods, and complex topic collections. And yes it is also that. But I see 99% of the apps to be small simple things that end users share with each other.

Where extensions extend the TWiki "machine", the applications provide inspiration and examples of how to use the machine.

I believe we mud up the whole thing by throwing it all in one big bucket.

We have encouraged people to post their apps in the Plugins (extensions) web for years. Only a few ever did and they were TWiki developers. We already know that this does not fly so why insist on keeping it this way? The little applications community has instead evolved in the Sandbox which has almost become the apps web to a degree that the sandbox has become a place we have to protect from the use it was intended for.

I want to continue implementing the Apps web in its own web like it was decided nearly a year ago. And it should be possible to find easily. We can perhaps find a better name for it. But it is essential to me that it clearly signals as being an end user area and not a developer area.

-- KennethLavrsen - 24 Oct 2008

I think the most important issue is to be sure to make the front page useful for a TWiki newcomer. So you present things sorted by "What are the things" but by "What goal do you want to achieve? / What problem do you want to solve". E.g: for the extension case, it would give 2 entries:

• webmaster I want to add a working, well tested, well documented feature to my installation
• developper I want to see examples of how to extend TWiki, even if not functional out of the box

One may add also:

• user I want to see some tricks to ease my user experience (some %SEARCH magic to put in my home page to see my edits, TWiki markups I can use in my page, these kind of things...)

-- ColasNahaboo - 24 Oct 2008

Oh my goodness! You just perfectly prooved what I said when talking 'bout how experts see the world. While Kenneth argumentation for apps in a space of its own is valid it still mixes up different issues.

One is "how to organize one out of n repositories" and the other is "how to access the repository I need". Two entirely different issues! (there are more than that but they are not relevant in this context).

In this context the goal of everyone who's visiting TDO is to add something to the "out of the box" TWiki as it is in the *zip file. Try to see it from a linguistical point of view not a technical and you will see that "The applications web [Kenneth] wants to drive" has very well something (if not everything) to do with extensions. It does not matter what you want to add to your TWiki (a service, a plugin, a skin, a pink pony)...

The fact is you want to extend TWiki's functionality.

If you have this in mind, what is easier?

Option 1: n links to specific repostiories.

Option 2: one link to a repository landing page where we have more space to figure things out.

With option 2 the person who knows, has to click one more time. But with option 1 the person who doesnt, needs to think what he actually wants and needs to match this to our expert terminology. We are unneccassarily increasing the load of a person who's in an orientation mode.

Remember that we are talking about the home page and the primary navigation! The purpose of this page/page area is to provide fast and intuitive acces to the information I need. It's not an index page.

If the goal is to add something to my TWiki and there is just "Extensions" it's a mindless choice. I f there's Apps and Extensions I need to think about what they might mean and my flow is interrupted.

Simple as that.

-- CarloSchulz - 24 Oct 2008

I'm definitely on your side in this argument. I can't see why you wouldn't just add TWiki applications to the (mis-named) Plugins web. We already do this with some TWiki applications (Bugs web, for example). The main problems are that we have no way of with packaging those TWiki applications to make them easy to bundle and upload, and then browsing all the extensions such that related extensions are.... well, related.

But isn't this a bit off-topic?

-- CrawfordCurrie - 24 Oct 2008

Yes and no. depends. It is part of how navigation is labled. But for everythings else, yes - off-topic.

-- CarloSchulz - 24 Oct 2008

Finding the right labels is so so important. For example "About TWiki" is rather elaborated compared to the terse "Apps".

- About - Extensions - Support - Community - Demos -

should make. We can then decide which content is reachable via Extensions and which via Demo. In anycase we need to really nail down the NewNavigationModelForTWikiDotOrg. There is some attempt to specify the first and second level categories but I have not seen any consistent integration of all of them and their ability to span the content we have and want to create in the future.

-- MichaelDaum - 27 Oct 2008