Hi Paolo,
Am Montag, 31. Januar 2011, 23:20:18 schrieb Paulo José:
> Hi Björn!
>
> On 30-01-2011 13:47, Björn Balazs wrote:
> > First of all: Thank you - great work!
> > Your mocks point us to the unsolved fundations I wanted to work on
> > today, but unfortunately won't come to. But I will spend a couple of
> > hours in a train tomorrow, so I am optimistic I get to some results
> > then.
> >
> > The fundations we need to understand, before we can actually find a
> > really good interface solution is a clustering of the different types
> > of fields. You have done the clustering by "New" and "Existing". I am
> > not 100% convinced this is the best clustering, because it is too
> > general.
>
> Well, basically I understand there are 2 general actions related to
> fields from the user point of view: create and use them. It's my first
> thinking when needing a reference or other "meta" information about the
> document that I'm working.
I agree. This is the very basic differentiation. I followed that in the
mindmap. But I alos think this is not the most relevant differentiation for
about 99% of the use-cases. Because you can only create References, Bookmarks
(and I guess variables and stuff I do not yet understand). Nearly no users -
except from power users - will use this features. So this functionallity needs
to be there but should step a little to the back.
> When you need to create a field, there are different ways to achieve
> this depending of the type field. When you need to use a field, you
> *know* that it already exist, so its an automatic choice to avoid the
> first option "set a new field". And for any type of field you wanna to
> insert, it's the same workflow: you must 1. find the field, 2. choose
> how display the field information.
It is problematic that there are soooo many fields. This makes it hard to find
the field you want. This is way I tried to do some categorizastion of the
fields.
> > I would like to find someting between perhaps 5 to 10 (ideal would be 7
> > -
> > remember the limitations in the human short term memory) categories, the
> > user can decide in the first step.
>
> Well, the limitation of 7 rememberable of the human short term memory is
> a controversial issue... It seems to depend of context and other
> circumstantial factors.
It it one of the foundations of cognitive psychologiy. If you should have any
information that I do not have, please give it to me! You can of course use
methods of chunking to extend this information, but the number of 7+-2 simply
is the capacity of your short term memory. No discussions I know of :) (Ok,
can be less, e.g. when you drunk a lot of alcohol - but not talking about any
clinical aspects)
> If it is possible to limit the choice to a minor
> amount of possibilities, keeping it clear, why not do it? :/ Even more
> if you think in the future additions of new fields... Keeping the first
> step easy helps to make the next steps clearer.
If you take too few categories, the tree gets very deep. This is not good
either.
> > Each presenting again 5 to 10 fields that in the
> > next step can be configured (would give us room for up to 100 different
> > types of fields we can add to LibO, so making this a sustainable
> > solution for whatever kind of fields will be added in the future).
> >
> > My main problem here is, that I do not understand all types of fields
> > available - which would be very helpful if trying to find a decent
> > clustering...
>
> Yeah, this is a problem to me too. But I try to think in a field just
> how an information.
I suggest to rethink the whole dialogue. And we can only find the best
solution if we understand what users do in here and what they use the fields
for. I think the following is true, but I am not sure that is all:
> The user knows what wants and knows the computer has
> or can be have this information. The point is how to say to the
> computer: 1. which information you want, 2. what to do with this
> information.
>
> 1. Which information you want?
> - I want a information the computer already knows or I want [can to use]
> a new information
> 2. What to do with this information?
> - I want to show it in this or other way.
>
> From this point of view ("Which?" & "What?") is possible that the
> approach of Create/Use ("What?") and then choose the field type
> ("Which?") seems to be reversed, but if you perceive that some
> information can't be create in a dialog (like a paragraph per example),
> reversing them is a most efficient way to present these questions.
see above.
> > Additionally we should introduce some comfort functionallity like a
> > filter mechanism, recently used or perhaps even favorite fields for
> > quick retrival of the wanted fields.
>
> For sure its a great idea. Filtering by type or pattern matching,
> auto-complete the search, recently used shortcuts already in the first
> step (saving the last inputs for all steps), and grouping references are
> good ways to go! :D But we will need a big support from the developers
> and would be great have their help to know all the current possibilities.
We will need this anyway - and Cederic actually initiated working on this
topic. Hopefully he is not scared about the scope the whole discussion takes
:) - Cederic: are you?
> > Summing it up: Version 2 is much better than version 1, but still leaves
> > room for further improvement.
>
> I'd like to hear more opinions about it. I still think having a simple
> choice in the first step is better. :/ But of couse, my thinking is very
> much based in the *bad* only way I've imagined to display the Step 1 in
> the version 2. I hope we can find a better way.
>
> > Ok, more - including some mocks and a suggestion for a clustering -
> > hopefully tomorrow.
>
> We are doing big steps to the right direction. Its good when the doubts
> come up in the beginning!
I think so too. Looking forward to your input - and hopefully I will be able
to add some more content to the mindmap.
> See you, Björn! :)
You too!
Best,
Björn
--
Voluntary Open Source Usability: http://www.OpenUsability.org
Commercial Open Source Usability: http://www.OpenSource-Usability-Labs.com
--
Unsubscribe instructions: E-mail to design+h...@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
