Re: [libreoffice-design] The future of design suggestions

Hi All.

On 22/06/11 9:09 AM, Bernhard Dippold wrote:
> Hi Björn, all
>
> Björn Balazs schrieb:
> > Hi all,
> >
> > I am a little unsatisfied with the amount of individual threads going 
> > into
> > the direction of: "We need a new interface for LibreOffice - and it 
> > needs to
> > look linke this...".
>
> For me they show the high interest of our team members in the UI 
> design area. But you're totally right: We need to integrate the 
> different proposals in general directions for UI improvements.
> > This is a Free Software Project. As a design team, we will not need to
> > convince ourselves about this need to change the GUI (we all agree on 
> > that),
> > we will need to convince the people actually doing (and financing) it 
> > - the
> > developers and the companies paying them.
>
> Even if a large group of developers are paid by companies, there is 
> another group coding on their own.
>
> What we need are at least a few developers interested in UI design. If 
> we can convince them, our ideas will become code and finally find 
> their way into the product.
>
> But if we can convince more than just a few developers by showing the 
> needs our users to the entire community, this would get more 
> developers interested and involved...
> > [... we should never argue about personal opinions ...]
> >
> > So, how can we make this more productive?
> >
> > Ideas are good, visualisations are even better. So let us find a way 
> > to not
> > comment on these, but to collect them with the goal of easy 
> > comparision with
> > eachother. A gallary of ideas and visualisations of the future LibO.
>
> A gallery is great - but I'd rather think of a gallery of single UI 
> improvements (with visualizations from different mockups) than of a 
> gallery of the different mockups.
>
> If several mockups contain sidepanes, similar context menus or context 
> sensitive tools, these should be combined as features, based on user 
> data (already existing or new to be reached for) and expert 
> statements, decided on their positive/negative impacts and recommended 
> for implementation based on a specification containing all the 
> necessary information for the developers.
> > We should then try to extract the dimensions these ideas differ on. 
> > Knowing
> > these we can then again use user-centric methodologies to have the users
> > decide about what they like.
>
> Of course user feedback is the most important quality measurement for 
> UI modifications. But based on the user's likings it stays to us to 
> decide which feature should be implemented in which way:
>
> There are more than design aspects to consider (marketing, present 
> user base, documentation, coding effort, interdependency with other 
> areas of the product ...), users can't have in mind.
> > With this data we will have much less trouble to convince the 
> > code-sponsors
> > to go into a certain direction.
>
> That's true - real user data are a very good argument to convince 
> marketing and development ...
> > So - the main point I am argueing for is a gallery of interface 
> > ideas. Easy
> > to compare and on one spot. What do you think about this?
>
> +1
>
> I'd start with a gallery of the already presented mockups
> (perhaps with a short description of their features) and then go 
> through this gallery and collect the single features for another 
> gallery of UI elements / positions / ideas as a basic tool for our 
> overall concept.
>
> I don't know if a gallery or a table would fit our needs better.
>
> While a gallery is easier to create and maintain, a table allows to 
> add more fields than just one caption below each image.
>
> With a gallery we probably need to go to the gallery entry's wiki 
> pages to get the necessary information.
>
> A table (containing mid-size images in one of their columns) would 
> allow to add the features contained in the mockup, the rationale for 
> each specific design element (if existing) and many more information.
>
> On the other hand it's harder to write than just to the gallery.
>
> Best regards
>
> Bernhard
I also think it is important to be able to provide the whole package, 
complete solution, (all details) in an overall structured way and not 
haphazard. For a developer to pick it up and commit many hours all 
questions need to be answered in a specification. i.e. how will every 
menu in every LO component function. Discussion here is centered on 
writer and trying to conserve height but calc is mentioned as preferring 
wide to tall space.
May be a framework can be created, like a table, with the various LO 
components (writer, calc, etc.) across and the various UI elements down. 
When all the cells are filled and how the elements work, inter-reaction 
is seen and agreement is made then developers can be considered.
The developers may then need to refine this due to code or function 
needs (you can't do that because... but may be like this)
Then when all in agreement the coding can be implemented.
steve

--
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted