Warning: Can't find topic Codev.InterfaceThread
As long as we're looking a making a break from pure HTML, I strongly recommend that we examine the principles expressed of the book "The Humane Interface: New Directions for Designing Interactive Systems" by Jef Raskin.
(Also recommended by DickKarpinski. Here's his review.) Amazon with detailed reviews, Barnes & Noble
Here are some of my notes about the book.
My Incomplete Notes,
Another review, And Another
It might make the difference between an application accepted by the corporate world and one that is not.
Basically his point is that the best interface is human memory and the best input is commands entered by keystrokes. This reduces pop-ups (which interrupts train of thought and workflow) and skipping from page to page to page to perform the equivalent of a single command. Eliminate "Modes". As this applies to Twiki... imagine Twiki as a single page in Book-View of all topics. Search just positions within the page. All commands and searches are entered right into the text you're viewing. All changes are entered right into the text you're viewing. Keep complete logs and undos for all changes. Lose nothing. Always ask yourself why the user is performing a given command and make a new command specific for what they wanted to do in the first place (refactoring commands). All this keeps things simple, simple, simple.
Also look again at the book "Don't Make Me Think" by Steve Krug ( available at
Barnes & Noble ) which PeterThoeny suggested in HierarchicalNavigation.
-- SocinianClarke - 24 Sep 2001
Here's and interesting new idea that seems to lend itself to wiki culture: Building the Organic Portal . . . One Visitor at a Time
"One portal is taking the polar opposite approach to organizing information [from traditional portals]. I call it an "organic portal."
"Ant trails that lead to sources of food are continuously reinforced, through the movement of ants as they go backwards and forwards..."
"If sources of information are substituted for sources of food, it can be seen how a similar system might be used by people to guide each other to information...."
"Cancer Treatment World takes into consideration the reluctance of people to get involved in community projects. It provides each visitor with an invisible set of genes - in the form of javascript modules built into Web pages - that allow them to read and lay pathways..."
-- SocinianClarke - 26 Sep 2001
The tree of FilebrowserLikeNavigation would be in indented cells of the table... each one editable (except the commands which would be buttons the size of the cell).
It's also easy to make tables into little, on-the-fly databases.
WikiWord would work the same (though appear to re-position within the table rather than "go to next page"). This way, cells could be giving labels and properties for programmatic manipulation.
Copy and Paste would be easier and more precise. A single Copy and Paste could also be done across multiple Topic/Pages with one command.
Empty cells could also act like quick, little, easily reached, near-by command lines. (This skips the use of the buttons for the advanced users.)
Security could be at the cell level.
means "Wrap cell contents around Horizontally" so:
Topic
Topic1
Topic2
Topic3
Topic4
Topic5
Topic6
Topic7
Topic8
or
Topic (with subtopics)
Topic1
Topic2
Topic3
Topic4
Topic5
Topic6
Topic7
Topic8
becomes
Topic
Topic1
Topic2
Topic3
Topic4
Topic5
Topic6
Topic7
Topic8
means "Make cell list Vertical" so it's the reverse of "Wrap cell contents around Horizontally" above.
Basically the content cells, command buttons, parent topic, and ref-by are all just properties of the Topic cell.
This organization might make supporting XML and OOP design easier.
Keep columns to <= 10 to try to match the "7 +/- 2" psychological principle.
Infinitely scaleable due to its basis in a database structure for its back-end data storage.
My ideas are a little more developed than this. I'll add details if you're interested.
Here's a crude sample:
ThisTopic/PageName
Paragraph1
(click inside a cell to edit)
Paragraph2
(navigate all cells by arrow keys)
Table1Cell1
Paragraph3
(navigate to buttons by command key shortcuts)
I take it this would be a replacement for the search page?
I think we need to keep in mind the needs of users using a dial up connection.
-- RandyKramer - 27 Sep 2001
Well, [blush] I was thinking this format would replace every page. So, it's more of an User Interface change than a navigation change, but it affects the navigation by making everything collapsible. Thus, navigation does not require a second window pane.
This format would make every page (or every cell) a search page.
Regarding bandwidth concerns, if Twiki is really targeted to the corporate world, bandwidth concerns should (in my opinion) take back seat to usability and clarity of function and purpose. This format should also be designed to digress back to the current Twiki format (for the bandwidth challenged).
As you know, there are many techniques for circumventing the bandwidth challenge. Flash has one, Real-Player has another. If some very desirable plug-ins require Java Script to interpret the data for display, this format could do the same. Also, the browser could give the illusion of scrolling through a big page, by the server sending just the rows visible and sending each additional row upon scroll up/down. This is a common database technique that could be applied here.
-- SocinianClarke - 27 Sep 2001
This sounds to me that what is being discussed here is basically collapsing an entire TWiki web into a single page. How would concurrent edits (and locking) of a single cell be handled? Updates of a cell? Revision control? Seems to me this would require every element (cell) to be in a database with individual row level locking.
An interesting idea but implementing it sounds scary and complicated (coming from a non-programmer). Perhaps if a true DatabaseBackedFilesystem were available that would change. MetaKithttp://www.equi4.com/metakit/ might fit the bill for proof of concept.
-- MattWilkie - 27 Sep 2001
I get the idea, but the implementation, if it literally looks as imposing in a production version as above, undermines the whole simplicity idea, no matter how simple it really is. The advantage of Wikis comes at least as much from the visual, the esthetic side, the simplicity of the page, and then the realization, when you click Edit, that you can just...edit away, is great, Wiki's central strength (also what will put off some people permanently). When you check out c2 site or UseMod, they're so quick and simple and direct, it's almost shocking that TWiki behaves the same way with all the extra gear that's loaded in. The secret is keeping it all transparent (to the user, and to the admin, too, on that level).
I mention this particularly 'cause I checked out some of your links and found this - a book quote or your notes:
"When you want to set down an idea, you should be able to go to your computer or information appliance and just start typing...If a system's one-on-one interaction with its human user is not pleasant and facile, the resulting deficiency will poison the performance of the entire system that system might be in its other aspects."
That's EXACTLY what I was thinking a few minutes ago when I added a couple of points to UsabilityIdeas. TWiki could achieve a real ease of use for a wide range of applications, and for tiny groups up to large dispersed posses of thousands. At first glance, I don't see how the above fits into the Wiki way...too much red wink I'm always up to learn!
-- MikeMannix - 27 Sep 2001
I must agree with Mike. Whilst the concept expressed above is essential simple, the realisation looks very confusing. One small point on bandwidth. Many of us are used to high bandwidth, but it's not always available in the corporate setting e.g. dial up access, link between Eurpose and large parts of Asia etc.
-- JohnTalintyre - 28 Sep 2001
