For me the differences between tabbed menus with sub items and drop down
menus come down to this:
-- fastness --
* tabbed menu:
- 'same category items': 1 click
- 'other category items': 2 clicks and a page load (a click to open
another main tab, this needs a page load, then you can click on the sub
item you want)
* drop down menus:
- 2 clicks for everything. no page loads required . (some menu's can
expand without clicking on them, but you still have two 'focus points'
that the eyes and mouse pointer need to visit)
-- looks --
- This is very personal. IMO, the tabbed menu's are a bit more
beautiful then drop downs. But that is my personal opinion.
- I do think quick access to stuff is much more important then
aesthetics. Opinions can vary on this one too.
I don't really agree with most of the things you say.
IMO, one menu or the other is not more suited for a any workflow per se.
I'ld say that tabbed menu's are more fitted for cases where the user
uses a lot of the subitems of the same category. This menu becomes
inefficient when you need to jump between items placed in different main
categories.
Drop downs OTOH average out the access time for all sub items. Whether
you jump between totally different pages or stay in 1 main category and
access several sub items of that menu, the time needed to go somewhere
else is always very similar. I find it a misconception that going
between items in the same menu would be 'fast': you still need to go the
menu item, hover over/click on it so it expands, then go to the subitem
and click on it.
So I think tabbed menu's are good when you can categorize your items in
such a way that the user doesn't need to switch much between main
categories and visits sub items of the same main category mostly. Drop
downs are good when you fail to do that. (the user visits 'random' pages).
Keeping that in mind, I would say that tabbed menu's are always better
*if* we can predict the behavior of the user and that behavior is not
visiting pages randomly. Correct me if you disagree.
Okay so how do we reach a good categorization? For this we need to know
the use cases, like you said.
I see two options :
A) the user follows GTD. ( -> very predictable behavior, we can tune
the menu's for this)
B) the user does not follow GTD and has it's own habits. ( -> probably
there are some common habits, we can make some guesses and let
non-gtd-following people talk, but I don't really know)
( In what comes next, there are also some remarks how tracks would be
better suited and how some pages should be rearranged for GTD. )
A) GTD
These are the things that a user will do:
- enter thoughts very quickly into the inbox. Just thoughts, no
properties like dates, notes, contexts,... This is not a process but
happens randomly every once in a while
- process thoughts one by one to convert them into a project and/or
action, that could be given the someday context or not, file in
reference system (not implemented in tracks), add as note to existing
procect/action, or delete (when unimportant or can be handled right
away). This is definitely a process. But while doing it, the user
should be able to stay on one page (eg using ajax to update thoughts as
they are processed)
- look for a good next action. He needs a list that he can filter by
selecting one or more contexts. Yes i think action - context should be
n:m, not n:1. what I also find distracting about the current layout: if
you're looking for a task to do, then you are not likely to enter a new
task, so the 'add task' form is in a bad location like it is now. For
contexts and projects it's a different story. These are things that
where you need to manage: you need to have an overview and the
possibility to add at the same time. For those who think now 'yes but
we like to keep things uniform to not confuse people': People who
implement gtd will be delighted and even stimulated, not confused by
separating the 'add action' from the action overview.
- weekly review : check waitingfors, someday/maybe, projects, next
actions, agenda for next week. A full calendar is not - and should not
- be in tracks - , but a list of upcoming things for the next (2)
week(s) would be nice . It's also recommended to check the items on last
weeks calendar to check everything off, mentally. In fact 'collecting'
is in here too (but only collecting physical objects, so irrelevant
now). Also the processing process is part of the weekly review (i
personally do it more then one a week). The context/project/.. managers
also belong here. Reviewing and adjusting these things regularly is a
must.
'Weekly review' would make a great main tab with all these things as sub
items.
These are all very different parts of GTD that are in their own 'zone'
(state of mind). The user won't switch between them, he will focus on 1
thing and do it.
A notable exception is the first one (collecting of thoughts). A
thought can pop into your head at any time and you need to get it out of
your head, into gtd as quickly as possible, no matter where you are.
Thomasn proposed "adding an unstructured Inbox with a [______]
(send-to-inbox) input field on each page" to address that issue (
http://www.rousette.org.uk/projects/forums/viewthread/258/ ). Which I
find a great idea, especially for people who switch platforms often.
For people who stick with 1 platform can use a solution like
http://dieter.plaetinck.be/a_fast_way_to_get_stuff_out_of_your_head_and_into_your_gtd_inbox
to store stuff in a file or use the tracks api).
Maybe we should implement Thomas' idea and add a user preference to do
en/disable the send-to-inbox input field on each page.
As you see, when explaining the GTD way I also mentioned some things
that could be improved on the pages themselves. This is a different
subject then the organization of the menu, but when you separate
features from each other into different pages (or add them together on 1
page), the needed menu-items are affected too. So maybe we should
think first about any possible changes in the pages themselves and then
about a new menu.
B) is more based on assumptions then anything else I think, Assumptions
that might not even be true. Eg. do people who do not follow gtd really
want to add new actions while they are looking at the existing ones? I
find that hard to imagine. Other then that I don't know how non-gtd
people would (like to) use tracks.
Bsag explained her opinion/rationale behind tracks here
http://www.rousette.org.uk/projects/forums/viewthread/62/#151 but IMO
you can not really be a good GTD app by trying to keep things flexible
and general. ( that should be clear if you read all of the above). So
I hope she (and everyone else, of course) reads and thinks about this,
and replies of course :-) Maybe bsags opinion has evolved a bit over
the years? :)
I hope we can agree to make some stuff a little more gtd-ish, and if
not: we can also make things (like the menu layout ) configurable by the
user. We could provide a 'gtd' and a 'less-gtd' menu and let the user
switch, or even let the user customize everything (but still provide
templates for gtd/less-gtd). We could even adapt the pages to (not)
show specific elements depending on the users' preferences
Reinier Balt wrote:
Ok
I see two choices here:
· Look & feel: tabbed menu (like your netlog example) or
classic drop down menu's
· Ordening
Process driven vs. function driven
We need to think about the use cases here. Tabbed menu's are good from
the perspective from
a process driven design, i.e. I'm now going for a weekly review, so
I'd like to have relevant
functions for that. For example you can make a 'tab' review with
subitems Projects, Done, Tickler, Notes
Or a tab 'Work' with subitems Home, Contexts, Projects. You can think
of other tabs like Collect & Proces where
there are subitems like Inbox, Collect (for the work you are doing)
OTOH you can stick more to a functional approach where you have
classic menus to pick the functions
without a process as a context. You pick Projects when you need to do
something with projects being
review, work or collect&process. Since this approach is to find one
function and not follow a workflow, classic
submenus (where the submenu disappears after choosing a function) are
fine here
Ordening
This follows of course from the process or function approach.
Reinier
_______________________________________________
Tracks-discuss mailing list
[email protected]
http://lists.rousette.org.uk/mailman/listinfo/tracks-discuss
