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.
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.
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. 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.
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. 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.
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.
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!
See you, Björn! :)
~Paulo
--
Paulo José O. Amaro
Computer Science Student
Federal University of São João del-Rei
WebDesigner / Linked Empresa Júnior
Blogger / casatwain.com
--
Unsubscribe instructions: E-mail to design+help@libreoffice.org
List archive: http://listarchives.libreoffice.org/www/design/
*** All posts to this list are publicly archived for eternity ***
Context
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.