Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index

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

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

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 

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 

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

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

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!


Voluntary Open Source Usability:
Commercial Open Source Usability:

Unsubscribe instructions: E-mail to
List archive:
*** All posts to this list are publicly archived for eternity ***


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.