Hello Christian and fernando, thanks for your interest in improving libre office.
Well we are currently working on the best format to use in redesigning the LO layout in another email thread. Definitely feel free to work on proposals and get them ready for submission in the mean time. JL On Jun 2, 2011 12:28 AM, "jlopez777" <jlopez...@gmail.com> wrote: > 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 <imagin...@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 <christ...@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<sapi...@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+h...@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+h...@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+h...@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+h...@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
