Re: [libreoffice-design] [UX] organizing UX work on menus (was: Ribbons and Background color UX)

So before I continue with the wiki, should I just create a temporary
workspace, or direct it to the whiteboard listed, or create a totally
inhouse separate wiki with wikispaces? Either way, this is what I drafted
for structure and procedures. Let me know what you think.

Structure/Procedure Overview


   1. Master Layout
      1. Prioritization
         1. Research: Pull from what others have done as suggested from
         another team member since we don't want to recreate the
wheel...how well we
         do this can save us alot of time so i think its worth the
investment of
         research (renaisance project, openoffice data usage, LibreOffice beta)
         2. Issue dump: The reason why I say research before we "dump" a
         list of all the issues we want to work on is because there
might be a reason
         we may be unaware of that is the result of what we are
actually looking ot
         work on. This can help us avoid working on something halfway and then
         understanding the true nature and necessity for that component or
         fucntionality and drop it midway. Issue dumping is basically throwing
         together all the things we want to change in regards to the layout for
         improvement etc. It wouldn't be something that is dissected
and refined at
         this point. We just want a huge list of things, compile them in a more
         sucint list. This list would be maybe some descriptions
allong with some
         pictures of what we are describing.
         3. Once we have a cleaner more coherent list that summerizes to the
         best of our ability we would rank the importance of each
issue dump and
         maybe have team members either develop or find proposals for each item
         listed. Note that for every line item, it has a trajectory to
go on its  OWN
         stage process. I would reccomend not to take too much on but
keep it simple
         with tackling on a few items on the list at a time. But thats
just me.
      2. Brainstorming Stage
         1. Here we present proposals and tweak them for each item taken
         from the priority list.
         2. Here we compare which proposals and build upon ideas regarding
         general layout.
         3. Once we pick the BEST proposal it goes to the next stage of
         development
      3. Draft Stage
         1. Here we FINE TUNE the best proposal selected and focus on how to
         make this one idea as strong as possibl
         2. Here we would consider how any future changes of LibreOffice
         would impact the item design that is being suggested.
      4. Final Stage
         1. Here we go over the final vetting  and get it very to be
         produced on the official document foundation wiki
      2. Icon Placement (same thing as above, just simplified)
      1. Prioritization
         1. Research
         2. Issue dump
      2. Brainstorming Stage
         1. Proposal submissions
         2. Proposal tweaking
         3. Proposal selection for Draft Stage
      3. Draft Stage
         1. Final Tweaking of the proposal (that was selected via votes).
      4. Final Stage
         1. Last vetting process
         2. Polish for presentation to wiki page/developers with
         explanation, rational, and image mock ups.
      3. Functionality
      1. Prioritization
         1. Research
         2. Issue dump
      2. Brainstorming Stage
         1. Proposal submissions
         2. Proposal tweaking
         3. Proposal selection for Draft Stage
      3. Draft Stage
         1. Final Tweaking of the proposal (that was selected via votes).
      4. Final Stage
         1. Last vetting process
         2. Polish for presentation to wiki page/developers with
         explanation, rational, and image mock ups.
         3. Mock Ups/Descriptions
      4. Infrastructure
      1. Icon set
      2. Anything that can be downloaded that  would make the mock up
      process cleaner.


The reason why I think this would work the best is because how can we work
on placement of icons or functionality of context sensitive menus when we
don't agree on the general layout? The general layout would be the most
important in my mind because it is the foundation of where things will have
to go as we follow icon/toolbar placement. I think a big reason
why effectiveness eludes us is because in our minds we have different
starting points and assumptions about the layout. If we all agree to start
at the general layout, we have an opportunity to discuss and finalize the
direction and move forward to the details of the specifics of the layout.
Its not a perfect system but I think it has a chance at working. Lastly, If
someone doesn't like what we agree upon with the general layout, then they
can do their own stage process and look for input from other members.

I know this is alot to throw out there but breaking it up in this way seems
to make sense to me, but  thats just me.

JL

On Wed, Jun 1, 2011 at 2:25 AM, Phil Howard <imagin8or@gmail.com> wrote:

> > I'd be willing to set up any/everything that we need
> > ...
> > Also, I'm beginning to
> > feel like mailing lists are getting exceedingly complicated for our
> use...
> > Anyone interested in trying to set up a Google Wave communications
> platform?
> > -- Scott
>
> [delurk] When I joined the list a week or so ago I thought it wouldn't
> work, but actually this is a small team, and a wiki/wave would end up
> being stale. I would say the best mode would be to have the
> discussions in the mailing list (with links to sketches/mockups) where
> everyone who cares can contribute. Anything decided (meaning vague
> consensus) would then go in the wiki with a brief rationale. Then when
> people join the list they can see the summary of what's been discussed
> with the reasoning, without having to trawl a lot of stuff. I was
> overwhelmed by the volume of email, so I pick which subjects I want to
> participate in.
>
> Proper delurk: I'm a programmer with a very strong interest in UX and
> design in general. I'm keen on both preservation of existing
> interfaces (according to the UX principle that familiar is intuitive,
> and the coding principle if it works learn from it) but also on new
> designs that are completely different. On the Ribbon/toolbar debate,
> for example, I'd opt to provide a choice of toolbar, Ribbon and also
> new designs like dynamic context menus, docks and so on - that way you
> can iterate more rapidly on new interfaces without annoying everyone.
>
> Phil Howard (UK)
>
> > On Sun, May 29, 2011 at 04:55, Christoph Noack <christoph@dogmatux.com
> > wrote:
> >
> > > Hi Bernhard, all!
> > >
> > > Sorry for joining a bit late - I promise to leave early as well ;-)))
> > > But since the given questions / thoughts deal with stuff we've worked on
> > > since quite some years, I hope to bring in helpful information. If you
> > > like ...
> > >
> > > Am Sonntag, den 29.05.2011, 02:53 +0200 schrieb Bernhard Dippold:
> > > > jlopez777 schrieb:
> > > > > On Thu, May 26, 2011 at 6:06 PM, Phil Jackson<sapient@clear.net.nz>
> > >  wrote:
> > > > > > We need to have some sort of structured approach.  So any
> suggestions
> > > are
> > > > > > welcome - wiki or whatever.
> > > > >
> > > > > I think a wiki could work, I can get one up.
> > > >
> > > > You probably know that we have a wiki exactly for this (and other)
> > > > purpose(s):
> > > >
> > > > http://wiki.documentfoundation.org
> > > >
> > > > There is already a whiteboard area to work on such topics:
> > > > http://wiki.documentfoundation.org/Design/Whiteboards
> > >
> > > Yes, although I'd like to add that rather personal drafts / idea
> > > collections should be placed on personal Wiki pages. Since wiki allow to
> > > collect information quickly, teams usually run into problems later on -
> > > when separating valid information from outdated one.
> > >
> > > For example, I put my drafts on the "Temporary Work Space":
> http://wiki.documentfoundation.org/User:ChristophNoack/Temporary_Work_Space
> > > Concerning the structure - I can offer some "best practices", but we
> > > don't have a binding agreement on how to structure / handle specs
> > > (although one can look at the OOo Specification Project for some good
> > > ideas; or Ubuntu, or Fedora, or ...).
> > >
> > > Here is what I did when we worked on the improved printing for OOo/LibO:
> > > http://wiki.services.openoffice.org/wiki/Printerpullpages
> > >
> > >
> > > Personally, I'm all for good structure ... but the best structure
> > > doesn't help if the information isn't backed up / valid / supported.
> > >
> > > [...]
> > >
> > > > > > Is there some sort of tool we can use to poll members easily so we
> can
> > > get
> > > > > > an accurate idea of what ideas are popular and what are not?
> > > >
> > > > UX doesn't mean to poll members, but to get an idea what all our user
> > > > use and think - while the majority of them has never been able to join
> a
> > > > discussion on a mailing list (and thus all our contributions in this
> > > > area are just input from one very small group inside our user base).
> > > >
> > > > Björn proposed some time ago to introduce a facebook group where user
> > > > can provide their feedback to certain topics - such an area would
> reach
> > > > even more people than just our mailing list or wiki.
> > >
> > > No, unfortunately, we don't have such a tool yet - since day one (or
> > > so), I'm searching for somebody who might help to set up something like
> > > LimeSurvey, so that we might get an idea about our current user base.
> > > And, as Bernhard mentioned, Björn proposed to set up a "social group"
> > > that enables us to generate polls (which is better than nothing,
> > > although you have a pre-selected test sample).
> > >
> > > Björn also offered to test icons quickly - his company offers some neat
> > > surveys specialized for "agile usability".
> > >
> > > Furthermore we can use the following data sources:
> > >      * OpenOffice.org Usage Data (some raw data available)
> > >      * OpenOffice.org Renaissance User Surveys (analyzed data
> > >        available)
> > >      * OpenOffice.org Issue Votings
> > >      * Ubuntu Brainstorm (OOo/LibO)
> > >      * Ubuntu Papercuts Collection (OOo/LibO)
> > >
> > > At the end, the following matters: having someone who manages the
> > > required infrastructure, and asking the right questions to the right
> > > people (which is a lot harder as one might think *g*).
> > >
> > > > > at the most basic sense, we can do a google docs form and make it
> > > public and
> > > > > link it to the wiki.
> > > >
> > > > There already have been discussions on adding a voting extension to
> the
> > > > wiki - don't know at the moment how far this has gone. Someone might
> ask
> > > > at the website list about this...
> > >
> > > I don't know either - although I've used the voting extension only for
> > > rather simple stuff, like "do these guys like the idea at all".
> > >
> > >
> > > > > > We can make this a really democratic approach if is this is
> possible.
> > > > Don't know what you mean by "democratic" here. Of course we need the
> > > > feedback of our user base. But decisions about implementation (or
> > > > proposals for implementation) should not be based on such data alone.
> > > >
> > > > Effort and work for implementation, impact on existing users,
> marketing
> > > > consequences and our mission with platform independency are just a few
> > > > points that have to be taken into account.
> > > >
> > > > Sorry, democracy can only work, if all the people involved in the
> > > > democratic decisions have the same information and understand it's
> > > > importance to the entire community and our users...
> > >
> > > ... and I've never seen a working approach for that :-\ Instead, I
> > > propose to - at first - focus on efficiency which can be (sometimes)
> > > explained, (usually) perceived and (partly) measured. This is what the
> > > user base (99.5% of the people not within our community) expects - a
> > > working office suite for "them".
> > >
> > >
> > > > > I think we can to a certain degree. As long as we don't get stuck on
> > > syntax
> > > > > on questions for the polling, we would be okay. Obviously, we will
> have
> > > to
> > > > > take some sort of liberty of the starting point for how we frame the
> > > > > questions.
> > >
> > > This starting point might imply some assumptions ... which will require
> > > to know / focus on user types and their use of LibreOffice. And this ...
> > >
> > > Now we're back on track with regard to what the Design Team needs if we
> > > want to ensure good decisions. Before I went to "parental leave" mode,
> > > we've finished the list of things for the "ideal world" usability. I
> > > that it addresses most of your questions and concerns - now its "just"
> > > about solving these issues ;-)
> > > http://wiki.documentfoundation.org/Design/Kick-Off/WhatWeNeed
> > >
> > > Ah, Joed, that reminds me that you've asked a few days ago to know a bit
> > > more about the people here. We do have a Design Team page for those who
> > > want to share some information:
> > > http://wiki.documentfoundation.org/Design/Team
> > >
> > >
> > > > Of course - the only point to remember is what happened, when
> > > > Renaissance started their work: They had to repeat every now and then
> > > > that they don't copy MS ribbons - but they didn't manage to get the
> > > > message through, that their approach is independent and different.
> > >
> > > Yep, I've recently tested the LibO 3.4 Beta and was very happy that some
> > > excellent Renaissance stuff made it into LibreOffice ...
> > >
> > > To me, the most important "lesson learned" from Renaissance is: "A major
> > > overhaul won't work, because we have to - at first - clean up many
> > > different parts of the UI." So my approach would be (at least at the
> > > moment) to pick smaller items and to work on them.
> > >
> > > And, another "by the way", there have been a lot of different ideas for
> > > improving "the UI". Many of them had been collected/commented/improved
> > > in the "Design Proposals Collection, Accessing Functionality" we've run
> > > two years ago ... Liz was so kind to summarize the initiative (now
> > > featuring the neat Oracle design):
> > > http://blogs.oracle.com/GullFOSS/entry/renaissance_summary_of_ui_design
> > >
> > >
> > > > > > Otherwise does someone have a website page they can set up that
> design
> > > > > > members access and register their support for specific initiatives?
> > > This
> > > > > > would make it transparent to all.
> > > >
> > > > I don't understand this question at all.
> > >
> > > Do you think of something for Design Team members - or end-users?
> > >
> > > [...]
> > >
> > > > > > In the present format we are not as effective as there are no
> formal
> > > > > > procedures or structures in place. [...]
> > >
> > > True, see the WhatWeNeed list.
> > >
> > > Sooo, I hope you have a bit more information where we are, and what we
> > > need to go ... where we (probably) want to go. Tell me if you need
> > > further information ...
> > >
> > > Finally, thanks Bernhard for answering all these questions!
> > >
> > > Cheers,
> > > Christoph
> > >
> > >
> > > --
> > > Unsubscribe instructions: E-mail to design+help@libreoffice.org
> > > Posting guidelines + more:
> http://wiki.documentfoundation.org/Netiquette
> > > List archive: http://listarchives.libreoffice.org/www/design/
> > > All messages sent to this list will be publicly archived and cannot be
> > > deleted
> >
> > --
> > Unsubscribe instructions: E-mail to design+help@libreoffice.org
> > Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> > List archive: http://listarchives.libreoffice.org/www/design/
> > All messages sent to this list will be publicly archived and cannot be
> deleted
> >
>
> --
> Unsubscribe instructions: E-mail to design+help@libreoffice.org
> Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
> List archive: http://listarchives.libreoffice.org/www/design/
> All messages sent to this list will be publicly archived and cannot be
> deleted


-- 
Joed Lopez

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