Tags:
create new tag
, view all tags

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)
    Revision r1.7 26 Sep2001 16:19 GMT Writer Name    
 

Commands

Rev#Here
 

More

     
   
Rev#Here Rev#Here

NextTopic/PageName

 

    Paragraph1 (click inside any cell to edit)
    Paragraph2
 

 

Table1Cell1  
   
   
   
    Paragraph3
   
Attachment: Action: Size: Date: Who: Comment:
Sidebar.gif action 1682 23 Sep 2001 - 07:48 Peter Thoeny  
    Revision r1.7 26 Sep2001 16:19 GMT Writer Name    
 

Commands

Rev#Here
 

More

     
   
Rev#Here Rev#Here

AnotherTopic/PageName

 

    Paragraph1 (click inside any cell to edit)
    Paragraph2
 

 

Table1Cell1  
   
   
   
    Paragraph3
 

Commands

Revision r1.7 26 Sep2001 16:19 GMT Writer Name    

Search Results for: Brainstorm

 

     
 

 NextTopic/PageName
    Summary
 

 AnotherTopic/PageName
    Summary

 

     
 

 NextTopic/PageName
    Summary
 

 AnotherTopic/PageName
    Summary

 

NextTopic... AnotherTo...  
      Summary Summary  

 

Search Results for: Peter Thoeny

 

Search Results for: Socinian
     

Topic/PageWithDiscussion

 

    Topic Summary
 

-- Peter Thoeny -- 25 Sep 2001
 

-- Peter Thoeny -- 24 Sep 2001
 

-- Another User -- 23 Sep 2001
    Message Here
 

-- Peter Thoeny -- 23 Sep 2001
 

Commands

Rev#Here
 

More

     
   
Rev#Here Rev#Here
     Revision r1.7 26 Sep2001 16:19 GMT Writer Name    
   
   


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. MetaKit http://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


Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2008-08-25 - TWikiJanitor
 
  • 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.