Re: [libreoffice-design] Re: LibreOffice Tablet Suite

Hi Charles, hi Andrew, all!

Charles, thanks for the explanations ... although I wasn't able to
reply, I've read some of them at work (of course, during an official
break *g*). Very well explained, thanks!

Here another take ... and by the way, I read the remaining mails in this
thread. So Andrew, I might refer to this or that you wrote after this
mail.

Am Freitag, den 28.10.2011, 09:05 +0200 schrieb Charles-H. Schulz:
> Hello Andrew,
>
> 2011/10/28 Andrew Pullins <android2772@gmail.com>
[...]
> > we are starting from scratch here. yes the UI that Mirek has come up with
> > looks very much the same as his "Citrus UI" but that is the way it should
> > be(or at least if we decide to go with Citrus[which we should.])
> > of cores the interface that we have today would not be good on a tablet. I
> > have talked to a few people that USE pages on the ipad a lot at my church
> > to
> > make their sermons, and they have said that you can do too little in pages.
> > they want more tools with the tablet suite. they also say that because of
> > this they make there documents on the computer with M$ word. so some of the
> > curent UI should be put into the tablet suite.
>
> I think it would be very interesting to collect even more granular feedback
> on what they dislike with Pages from these people, do you think you could do
> that some time?

Yes, some qualitative feedback would be nice ... some hint: don't ask
for the features they miss, ask for what they wanted to do and where
they experienced problems. And, after finishing the interview, I suggest
that you ask what other office productivity suites they use - otherwise
its very hard to compare.

Why this approach? Because normal users always tend to answer they need
certain features, although they never use them ... it might sound
cold-hearted from my side, but here we need to protect them to fiddle
around with their choice :-) I once summarized that for OOo Renaissance:
http://wiki.services.openoffice.org/wiki/Renaissance/FAQ

(Sorry, wiki is down ... once it is back, you'll find something like
"Does adding functionality hurt?")

> > > - Designing an interface won't be everything. You can draw a beautiful
> > >  mock-up, but if the design/UX team does not translate it into
> > >  specification(s) it will remain a nice mock-up. Developers do not
> > >  know what to do with a mock-up, it can only be an illustration that
> > >  gives a general impression.
> >
> > what kind of specifications, from what Mirek and I have done so far what do
> > the developers need to make it work? from what I have done it it I can see
> > only one or two things that would need more explaining, which would be that
> > when typing the document the contextbar and maybe the top bar would hide
> > and
> > when press the bar that remains it would reaper.
>
>
> Oh... We are very, very far from even 20% of the job of a specification
> here. Here's a link that I found on a blog, it does not give you the precise
> manual to write a specification, but it gives you at least an idea of what a
> specification should contain:
> http://boadweelaw.com/blog/2007/02/15/how-to-draft-a-specification-or-requirements-document-for-a-contract/

Thanks for the link! Andrew, for LibreOffice, being an end-user software
for *many* people, we finally need to cover more. But let's explain that
step by step ...

A mockup or a blog post is great to transport an idea - to get interest
by other people and to make sure that those people see the potential.
But for the implementation (which is more than development) you need to
involve a lot of people.

Besides the explanations in the link above, you'll finally need
accessibility, translation hints, QA details, "edge-cases" behavior,
potential migration issues, ... 

Don't get feared :-) Turning an idea into a feature needs a bit
experience, but isn't black magic ... for example, when I did my very
first contributions for OOo, I "simply" reviewed a lot of specifications
by the Sun developers (Some years later, I was told that almost everyone
in the Hamburg offices knew me for that ...). Did that help? Yes,
because I did not knew the topic too well (like a new developer), so I
hinted towards missing / incorrect stuff the author simply assumed to be
known.

Back to the topic: A specification (or more relaxed: a whiteboard page)
for a rather complex feature serves as a hub that connects all the
different teams. André and I did a presentation on the LibO conference
explaining exactly that ... and you might be surprised what we need to
make sure that even tiny features work right from the start:
http://wiki.documentfoundation.org/cgi_img_auth.php/e/e6/2011-10-15v3_LibOCon_Non-Hacker-Tasks_Schnabel-Noack.pdf

Here is André's specification proposal:
http://wiki.documentfoundation.org/User:Andreschnabel/Spec_Calc_grid_lines_on_colored_background


> As you can see it's a full document that's needed, it describes very
> precisely each interaction of the UI. By the way, since what is needed is
> -at least for LibreOffice on the desktop- only one or two UX feature at a
> time, the document does not need to be overly complex and long, but you
> still need to have a specification describing everything, the layout,
> aspect, behaviour, intended goal of the feature, dependency,etc.

Andrew, my proposal to you is to pick a smaller feature - maybe
unrelated to Citrus, so that it can be really implemented (maybe an Easy
Hack?). How about doing that together ... with all the people on this
list?

> Christoph, do you happen to have a specification template?

Yes and no ... you already linked a whiteboard page, but we don't have a
template yet (because we did not decide on anything until now). André's
spec (see link above) was one proposal, my whiteboard pages (some of
them) also contain similar elements. A really great resource to get an
idea about "enterprise ready" specs can be found at the OOo
Specification Project:
http://specs.openoffice.org/

However, this might be overwhelming ... thus my proposal to do this
iteratively on this list :-)

Hope this helps!

Cheers,
Christoph


-- 
Unsubscribe instructions: E-mail to design+help@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
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