Tags:
create new tag
, view all tags

EZ Usability Upgrade Plan

A couple of problem stories by now have been repeated to the point of litany, and it adds up to: TWiki distribution and docs are totally programmer/developer oriented. Even "corporate" users are split between those w/ s/w skills and those w/o.

Used as an intranet (not a team collaboration/project tool), chances are the admin won't be equipped to do what's probably needed to get a basic custom set-up. It's pretty intense if you can imagine the position:

  • modify/create plugins in hours, maybe figure out core code and tweak too
  • whip up tables to use for specific searches tasks
  • configure a pile of custom regex searches with formatted outputs in plain text and metadata, in a couple hours
  • figure out templates and skins and design even a quick temporary look, hiding links you don't know from just yet
  • check the 50+ plugins and addons, go for at least 4-5...and see what happens
  • check out the variables, and then on to rest of the features
And that's assuming the install went fine, there's all that to do, with few examples in the docs or the basic installation, NO usable site configurations, just blank pages. Every program that's not already locked into an obvious mode, comes with at least one working sample: as starte ecommerce shop, a sample database...

The Idea: Obvious But Haven't Heard It Mentioned

What if "we" come up with, say, TWO types of common TWiki corporate implementations, say:

  • small department intranet (10-15 people)
  • project dev tool (collab, docs, tracking, doc/filesharing)
  • or whatever else...
THEN:
  • whip up a basic feature list and overall integration plan across 3-4 webs each site
  • hopefully a few people would spare an hour or two each and knock off a bit each: tweak a plugin, set up tables and formatted searches
  • if there's anything left, use a template or fix up the basic site look, add a logo, change colors, font

I'm not sure if this sounds unusual for an OS project, too much like work. To me, it seems the only way to go, or drop the non-dev market. (I just glanced at an installation basics crash course page...things are changing...)

Anyhow, this is one clear aspect. It overlaps but doesn't fix a few other things, like diffs tracking, new themes. But, if Peter and the Core dev team agree, I bet this could be done in three-four days, no strain.

NEW SPECIFICATIONS - as in, detailed descriptions - are what this approach would force. Filling in a Tips'n'Tricks / Cookbook randomly could take forever. A simple project requires a complete integrated system that can then be broken out, repurposed, etc. I always wonder for a minute with these ideas, clear to me, but... and then I think of people saying, It didn't work, it died, no-one used it, which I've heard from three or four people on this board, happened to me, it's kinda sad if PEOPLE CAN'T HAVE TWIKI.

I can do a first version of the NewContents docs organization, and help with the admincookbook. It would be like nothing happened, but things would be alot different. And I'm VERY clear on some major problems with small intranets...

Just to pound things in... (sorry)... one particular tune, times 3-4...


On Sun, Apr 14, 2002 at 06:33:12PM -0500, mike@gearcore.com
wrote: > Hey, Jane:

Hey Mike :)

> 1. How's the overall project going on your end? Are people
> using TWiki? Is the simplified version helping? 

doesn't work really: people are coming by to have a short look,
but no groups asked for a 'project' and no people seem to want to
do some editing.

as the TechPage is being requested by most visitors i intend to
keep the site in place: maybe people are using it anyway.

>>> On Mon, 1 Apr 2002 12:11:23 -0500, Lisa Scarbrough
>>>  wrote:
>>>
>>>> I noticed you did a great deal of the documentation on
>>>> Twiki. I'm hoping you can help.   
>>>> > On Mon, 1 Apr 2002 12:11:23 -0500, Lisa Scarbrough 
>  wrote:
>
>> I noticed you did a great deal of the documentation on Twiki.
>> I'm hoping you can help. I just downloaded and installed this
>> for my company, but we are having a problem
>> [SNIP!]
>> I was curious if you knew how to make a discussion board
>> in Twiki. Most of the users know very little other than how to
>> send an email message.

COUPLE DAYS LATER:

I've already spent so much time setting up the webs for 
all our current projects, and I do like the concept of 
TWiki. I just have to find ways to make it easy to use 
for people who aren't very computer/web savvy.

Lisa Scarbrough-Sinclair

I find the *documentation for Twiki hard to read*. I do not 
know much about the twiki community so *I have not expected 
context for this tool*. The manual is written *more as a 
programmer reference manual then an introduction*. It would 
greatly help me if the Overview section of each chapter 
contained *some "Use Cases" for me to develop context*. I would 
like the manual to *speak more of the language of the users of 
the system and less of the language of the people who wrote 
the code*. [SNIP] Why would a user use this feature (skins, 
templates)? What purpose would the user be trying to accompish? 

This could be either "goal oriented" discribing a general 
goal OR using a specific simple example use (use twiki as 
a "bug tracking system"). 

-- Main.KenEstes - 13 Dec 2001 

Whole point is: TWiki is cool and powerful and highly 
customizable. And Twiki core team can customize it in no 
time. But admin starting with Twiki (and as in my case, 
also with Apache, Linux and HTML) has bigger fish to fry: 
to design webs, create some contens, get site up and running! 
So s/he lacks time to research how to customize templates, 
might be scared to rename Main to User etc. If Twiki wants 
to increase user's appeal ist better to put "best foot 
forward", to hide advanced features (just one click away). 

-- Main.PeterMasiar - 28 Jan 2002 

-- MikeMannix - 05 May 2002

I've just floated a compatible although different approach to provide EZ paths for upgrading usability of a TWiki site at TWikiToolChest. I came back to take another look at your proposal and reflected that my proposal would also address (perhaps even more directly) the frustrations of folks in the examples given above. That being said, I also think that this is an excellent idea.

-- LynnwoodBrown - 07 May 2002

I am always a proponent of simple first steps that go in the right direction. My suggestion is to split the documentation into several big parts.

  • Installing
  • Administration
  • Use

The TWikiDocumentation is one big file with everything interspersed. Unless I am misinformed about the availability of this sort of documentation, I will be splitting it myself at least to isolate the user information from the much more administration and wortless-once-installed installation information. Also, some administration stuff is embedded in the documentation, such as creating new webs, etc. which could be more appropriately placed in an administration web.

-- RaymondLutz - 29 Sep 2003

TWikiDocumentation is in fact composed out of smaller doc files. But it would be very useful to target user problems (users as corporate tech people, admins, SIG owners, end users), and label each section clearly. All those different users have different problems and their general knowledge on CMSes and wikis will vary wildly.

The rest of my comment in CommunicatingTWiki.

-- ArthurClemens - 01 Oct 2003

Edit | Attach | Watch | Print version | History: r6 < r5 < r4 < r3 < r2 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r6 - 2006-02-04 - PeterThoeny
 
  • 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.