Tags:
advocacy1Add my vote for this tag customer_focus1Add my vote for this tag documentation1Add my vote for this tag navigation1Add my vote for this tag stale_content1Add my vote for this tag usability1Add my vote for this tag create new tag
, view all tags

Customer Focused TWiki.org

This is a working document, please help improve it

Introduction

TWiki.org's layout and navigation model currently is developer centric. TWiki will get more exposure if we change that to be more customer focused, which in turn makes the TWikiCommunity happy. We can achieve that by creating a good navigation model, layout and content for the most common use cases.

Related topics:

Common use cases

  1. Press/analysts looking for what TWiki is, where in the collaboration space it is, where we are going
    • Clear documentation, ready to copy & paste
  2. Managers looking for why they need TWiki
    • Benefits, ROI, etc
  3. Evaluators comparing TWiki with other collaboration systems
    • Tour of main features, screenshots, etc
  4. Administrators looking for help on maintaining TWiki
    • Documentation, how-to, support
  5. Users looking for help on using TWiki
    • Documentation & how-to for beginners, documentation & how-to for advanced users, support
  6. TWiki community working on TWiki core and extension
    • Links to all aspects such as documentation, brainstorming, feature tracking, bug tracking

This is a good opportunity to introduce Personas

Top level Navigation/Layout

TBD

Content by use cases

Entry points and content by use case:

  1. Press/analysts:
  2. Managers:
  3. Evaluators:
    • Entry point: TBD
    • Topics:
  4. Administrators:
  5. Users:
  6. TWiki community:

TWiki Tour / Screencast

One high impact document is a TWikiTour that highlighs the value, power and ease of use of TWiki. Many commercial vendors do a very good job on that, and we can steal^H^H^H^H^H borrow some ideas. Examples:

All have a simple navigation with previous, next.

The TWiki Tour deserves a box as big as the Download box on the twiki.org home page.

Alternatively, a screencast (digital recording of computer screen output with audio narration) is a good way to introduce a product to a person with sort attention span. Example:

Location of content

The physical location of the documents is relevant, but not that important. The navigation makes it obvious where you are, and links can be done between webs. An obvious choice is to create SupplementalDocuments in the TWiki web as described in WhereToPutOfficialDocsMissingInDistro.

Measure of success

A simple proxy for the measure of success is the number of downloads per day. We are currently at around 400/day.

  • Measure of Success: 20% increase of downloads one month after rollout of initative

-- Contributors: PeterThoeny, LynnwoodBrown

Discussion

Yesterday I had a lengthy phone conversation with Lynnwood. Among other subjects, we discussed the TWiki.org navigation model and found that it can be improved a lot. If we address this with high priority we get a measurable result soon, which hopefully helps in boosting the morale of the TWikiCommunity. Lets do something where we can see a result!

Yesterday I got interviewed by an analyst. It showed clearly that analysts have different interests/needs compared to evaluators and administrators, hence the need to create a navigation model that fits different needs.

Arthur posted a good start in ManageStaleContent:

  • Home (shortcuts to download, TWiki features, Success stories and TWiki in the news)
  • About TWiki (TWiki features, Success stories and TWiki in the news)
  • Development
    • Plugins
    • Archived development topics
    • Sandbox
  • Documentation (lots of the current TWiki web)
    • Cookbooks
  • Support

We can learn from the web sites of commercial companies. They do a very good job on PR, such as the feature demo of WetPaint.

There is a lot of (IMHO currently not so productive) discussion going on on restructuring the Codev web. Lynnwood and I believe that the Codev web restructuring is important, but that a better navigation model on TWiki.org that is customer focused has higher priority.

If you find time, please help improve above document. We can start working on the content once we have a clear picture on the "how-to".

-- PeterThoeny - 10 Mar 2006

I agree this is very important. I have been forced to both create my own documents for the current TWiki app I'm working on and, more often, to refactor existing ones, because the current ones -- at least as organized and clumped together -- are unuseable to the typical user.

But isn't another very important step moving twiki.org to Dakar? The stuff I'm writing/editing isn't going to make it to twiki.org otherwise, IFAICT.

-- MeredithLesly - 10 Mar 2006

Extending Arthur's proposal, I think a good layout of webs could be:

  • Home (users & groups, shortcuts to download)
  • About TWiki (shortcuts to download,TWiki features, Success stories and TWiki in the news)
  • Codev
    • Archived Codev (stale content, cruft)
  • TWiki (Aditional Documentation)
  • TWikiX (documentation of the release X)
  • TWikiExtensions (everything in Plugins, sans the docs)
  • Support
  • Sandbox

Is not "that" different than the current layout. Codev may remain a "brainstorming" web where all the content is generated and later moved to it's proper place (this last part is really important), and stale content is moved to Archived Codev from time to time.

With this layout, PR material will be separated from the creative chaos that is Codev, and could be more appealing to Press/analysts, Managers: and Evaluators:

Also... a skin specifically designed for TWiki.org could be good, don't you think?

-- RafaelAlvarez - 10 Mar 2006

Section labels should be understandable by visitors, both casual as frequent; the labels should convey their meaning. In the above example,

  • "TWiki" doesn't tell me it is documentation, "About TWiki" and "TWiki" seem to be the same from the outside.
  • "Home" cannot 'be' users and groups; its not a directory.
  • "Codev" is not clearly labeled "for developers".
  • "TWikiX" (I assume TWiki4, TWiki5 etc) does not tell me the goal: is it documentation? is it download? Current development?
  • TWikiExtensions is a WikiWord and I would avoid that in "public names". I am not sure if plugins is a better word than extensions, but in any case it should be targeted to developers.
  • Noone will be interested in Sandbox without introduction, so it might be as well one level deeper, making room in the main navigation.

What is important in developing site entrances is to think about target groups. The section "Common use cases" is a start.

-- ArthurClemens - 10 Mar 2006

Just a small though snippet for Users looking for help on using TWiki (support). What are these people doing on that web? Trying to find an answer to their question: "has this been asked before?" "what was the answer?" "is this still relevant?". When such a user browses the Support web, it is hard to get orientation points. New topics have a green "NEW" symbol in the list, but other kind of topics?

It would be really helpful to them if topic listings (from any search) would show (with a color or color+symbol) if a topic has been answered ( of course, answered questions are valued higher than unanswered questions). Also the top of Support webhome does not show any answered questions: these are way down, even below the "ask question" form which is bad.

It could also be helpful to facilitate browsing by category (Autorization, Search, Fatal error, etc): FacetedNavigation.

-- ArthurClemens - 10 Mar 2006

Arthur, I agree with you. The "problem" is tha Webs are shown by name and not by title. That's why I think that the SiteMap could be good, if it wasn't so "ugly".

With those containers for the topics, it should be possibe to build the proper navegation with the right labels to be user-friendly to first-time users. I bet that Long-time users (active members of the TWikiCommunity) will feel at ease with the web names.

-- RafaelAlvarez - 11 Mar 2006

How much attracted would a manager be to a link labeled ValueOfTWikiForManagers? Or would it be better named Value of TWiki for Managers? (Or would there be a section on the homepage named "Managers" that would list a number of targeted links?)

So yes, web names are not conveying their meaning enough. Web names are ok for long time users or trained users, not for casual visitors.

-- ArthurClemens - 11 Mar 2006

I agree.. But this won't be possible until Edin*, unless the site is built in a way that relies heavily on the [[]] sintax.

-- RafaelAlvarez - 11 Mar 2006

On a TWiki Tour: A short video/flash show is a real killer app for advocacy. Joel on Software knows what he is talking about in his rant on Ruby on Rails, "a light webserver, ORM, templating language, code generator and pre-built templates are nothing new, but a killer viral 5-minute video demo of all those things working together brilliantly is".

-- PeterThoeny - 13 Mar 2006

TWiki.org site structure proposal (and in progress):
TWiki.org site structure proposal

-- ArthurClemens - 17 Apr 2006

Arthur - I like it. It would be great to use English, rather than 'Codev, TWiki04, Know' !

Also makes me wonder if we couldn't just install TWiki4, and then provide a UI to allow people to bring across old documents from the current TWiki.org site - providing an interesting platform for refactoring the site. (and thus all the old content would be archived on the cairo based one, acessible, but in 'secondary storage'

-- SvenDowideit - 17 Apr 2006

English. What a concept!

s/English/natural language/

-- MeredithLesly - 17 Apr 2006

I also like this logical structure. Can be presented as such in the UI, e.g. with a display web-name shown by the skin. I have done that in the past with a better HomePageNavigation that made it possible to navigate a TWiki site with 70K topics.

-- PeterThoeny - 17 Apr 2006

It looks great, a vast improvement. I'd like a strong link from Support to Documentation, to make sure users seeking support are steered towards searching in the right place to get answers.

But I don't see the Plugins web anywhere above? Are we to assume that Plugins continue as-is? What about the issue of shipping plugins for different TWiki versions (the current solution is less than ideal).

One possible approach would be to attach tested plugins to the TWikiXX webs, and keep the Plugins web itself for Dev discussions.

w.r.t navigation, why not use Arthur's picture for front-page navigation? (I added sensitive links to some of the boxes below)

http://twiki.org/cgi-bin/view/http://twiki.org/cgi-bin/view/Codev/http://twiki.org/cgi-bin/view/Supporthttp://twiki.org/cgi-bin/view/http://twiki.org/cgi-bin/view/TWiki03http://twiki.org/cgi-bin/view/TWiki04http://twiki.org/cgi-bin/view/Pluginshttp://twiki.org/cgi-bin/view/TWiki03http://twiki.org/cgi-bin/view/TWiki03Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)Drawing is not editable here (insufficient permission or read-only site)

-- CrawfordCurrie - 17 Apr 2006

A site structure = web structure is a "nice to have", but I do not see this as a requirement. In fact, it will get obsoleted quickly with the next restructuring. And CoolURIsDontChange.

I prefer to have the site structure displayed prominently by the UI, e.g. the skin showing a display name of the web. I do not see a need to create a new web for a handful of topics. For example, the few flash tour show cases can be located alongside the documentation in the TWiki web, and marked prominently as show cases. Hence site structure != web structure.

-- PeterThoeny - 17 Apr 2006

I wouldn't worry too much about cool URIs, because TWiki does not support them (See article by Tim Berners-Lee).

It is far more logical to have a url like twiki.org/showcases/ then twiki.org/bin/view/TWiki/TWikiShowcases. Especially when you get more than one showcase page: twiki.org/bin/view/TWiki/TWikiShowcase01, twiki.org/bin/view/TWiki/TWikiShowcase02 etc.

  • i've always assumed that each showcase would get its own subweb -- WillNorris - 17 Apr 2006

Cool URIs would be:

  • twiki.org/showcases/Motorola
  • twiki.org/showcases/Harvard
  • etc

Also note that Wikipedia has cool URIs: you can enter a url like wikipedia.org/einstein to land on http://en.wikipedia.org/wiki/Einstein.

-- ArthurClemens - 17 Apr 2006

As I've noted elsewhere, I think, webs are meaningful in a number of ways and the ability to have multiple webs and the ability to customise each of them was one of the things that attracted me to TWiki in the first place. I agree that site structure \!= web structure, but web structure is an important part of site structure, with each webs having the ability to have a different look, functionality, navigation ability, etc. Smart web structure is not enough to organise a large site, but it is a key part of it IMO. I don't understand why you frequently seem to diminish one of the (many) distinctive features of TWiki rather than embracing its usefulness.

-- MeredithLesly - 17 Apr 2006

i suspect that one reason would be that FindElsewherePlugin isn't installed here. it does address most (all?) of the "inconveniences" of having multiple webs. (it also means you don't have to type Main. or %MAINWEB%. anymore to refer to people!)

-- WillNorris - 17 Apr 2006

I drove PleaseInstallPluginsAtTWikiDotOrg with a bunch of such plugin-install requests. After him up above ignored/refused I've become too apathetic to bother suggesting anything there anymore.

-- MartinCleaver - 17 Apr 2006

Here is a good example of a wiki demo: WikiRadio.

-- PankajPant - 17 Apr 2006

PeterThoeny wrote, "_site structure_ != _web structure_" and pointed to HomePageNavigation. i completely agree with both of those points. virtual navigation doesn't have to line up with any sort of physical mappings. so, let's gut the existing WebHomes which somehow manage to simultaneously provide too much information and not enough. start at the top and what doesn't get relinked effectively falls by the wayside. what else? documentation needs to be refactored and creating a new web isn't a requirement to do that. too often documentation for a given topic is spread around so many different pages (not to mention how out-of-date some topics are). i feel some massive top-down refactoring is the best way forward, but who's going to do it?

i don't understand why http://twiki.org/ doesn't redirect to one of the web's WebHome's, but that's a separate matter...

did i just wrap this topic to CleaningUpCodevRevisited?

(sorry if that is incoherent rambling, i really need to go to sleep...)

-- WillNorris - 17 Apr 2006

When I design a site structure for a client, we never talk about creating as few directories as possible. I do not see a need to create a new web for a handful of topics is never an issue - perhaps "Contact" only has 3 pages. We do talk about creating attractive site entrances and logical and memorable groupings. Why are TWiki webs considered so 'expensive'?

Perhaps we need to consider the idea to let twiki.org have a TWiki, instead of it being a TWiki. Lots of pages (and "directories") could be static pages, published from TWiki topics.

-- ArthurClemens - 17 Apr 2006

We must take into account the different "need" that different sites have. A site where most of the content is semantically coherent don't need many webs, the navigation schema is simple and it could be modeled with "virtual webs" and managed by gateways topics, the proper links in the left bar and perhaps even with tags. But a site that has web that are semantically unrelated (and twiki.org falls in this category) needs at least one web per semantic group to have an effective navigation.

One of the main advantages of having a web instead of a virtual web (as was pointed out in DiscussionAboutNewTWikiWebs is that they can have customized WebHomes and WebLeftBar that actually enhance the navigational experience of the user.

From thatp point of view, having webs that are semantically coherent not only help to keep the content organized, but actually helps the user to navigate to the information he/she is looking for.

OTOH, the user should never, ever notice that there are several webs. They must see a continuous flow between them, starting in one and ending in another without noticing, being able to track back at any time. The webs must work with synergy.

-- RafaelAlvarez - 17 Apr 2006

In CsaSite (which I've put there for wont of a better place), I've started to describe my current project and, among other things, why a lot of webs is the right thing for this project.

-- MeredithLesly - 14 Jun 2006

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng TWikiDotOrg-structure.png r1 manage 38.5 K 2006-04-17 - 00:33 ArthurClemens TWiki.org site structure proposal
Unknown file formatdraw untitled.draw r4 r3 r2 r1 manage 7.4 K 2006-04-17 - 07:50 CrawfordCurrie TWiki Draw draw file
GIFgif untitled.gif r4 r3 r2 r1 manage 3.8 K 2006-04-17 - 07:50 CrawfordCurrie TWiki Draw GIF file
Mapmap untitled.map r3 r2 r1 manage 1.6 K 2006-04-17 - 07:50 CrawfordCurrie TWiki Draw map file
Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r32 - 2007-09-07 - MichaelCorbett
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.