New on the wiki!

classic Classic list List threaded Threaded
42 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack
Hi Graham,

some short comments...

Am Samstag, den 31.01.2009, 14:48 -0800 schrieb Graham Perrin:
>
> Christoph Noack wrote:
> > The ux-discuss is used [...explanation...]

> My route to discuss@ux was this:
>
> 1. involvement with another open source project where discussion in the bug
> tracker was actively encouraged
>
> — moreso than in the (Google) group forum
>
> 2. finding the alt-key conflicts/failures in OOo 3 for Mac OS X
>
> 3. discussion within Bugzilla (based upon past experience, this seemed
> natural and preferred)
>
> 4. direction from Bugzilla, to discuss@ux

Okay, up to this point, we don't have any influence - if we didn't
caused the bug ;-)

> At that point, I found the order of things at
> <http://wiki.services.openoffice.org/wiki/User_Experience/Community/How_To_Join>
> surprising.
>
> I had been simply: directed to a list, for discussion, mainly in relation to
> a single bug and its dependencies.

That is rather surprising to me... Personally, I don't like to enforce a
membership for people who just have a question. That does not make
sense, especially since CollabNet is not a real help here. The
membership is targeted at people who are generally interested in UX. And
to better support them, we do ask for so much background information.

> Was my route to chatting in a bar or café simple?
>
> The next requirements were to:
>
> 5. formally join a team (about which I knew nothing)
>
> 6. register at a wiki (I don't like wikis)
>
> 7. subscribe to a mailing list (that is not designed for attachments).
>
> Don't get me wrong — I now enjoy membership of this community, and issues
> are being addressed — but IMHO the desirably simple steps to discussion are
> unnecessarily convoluted.
>
> I should not have to formally join a team, then register and edit a wiki,
> then subscribe to a mailing list, to simply discuss a bug.

Joining the team and subscribing to the mailing list is required by the
CollabNet infrastructure to post messages. Okay, if messages are sent to
the list without being subscribed, then the administrators can accept
the mail anyway. But for usual discussions, yes, this is the way to go.

> Please, can we gently review the required order of things at 'How To Join'?

I would rather discuss how we can handle such requests like yours - the
How To Join seems to have an other target group.

(And an except of your last mail which just arrived...)
> I forgot to add, the new wiki page does look much better than when I
> joined
> :)

Does it look better, or is it more helpful? If the latter, then please
give us a clue why? Thanks!

Bye,
Christoph



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Width not exceeding 150 characters: origin, pros and cons (was: New on the wiki!)

Graham Perrin
Administrator
In reply to this post by Clément Pillias
Clément Pillias wrote
not a good idea to have text using all the width of the page (especially if you have a big screen). A better readability is achieved when the line width does not exceed 150 chars.
Interesting, I find completely the opposite. I love texts that extend from far left to far right of my display (1650 pixels). YMMV.

When I encounter a column of text that is too narrow: I often send the content beyond the web page, to be read more easily in some other application. I tend towards Tofu, in which the right arrow (not the page down key) scrolls smoothly to present the next screen.

I don't argue for a change to whatever standard is preferred for the masses, but I'm curious to know the origin of the 150 character guideline.

TIA
Graham
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack
In reply to this post by Clément Pillias
Good evening Clément!

Am Samstag, den 31.01.2009, 14:11 +0100 schrieb Clément Pillias:
> Le 30 janv. 09 à 23:31, Christoph Noack a écrit :

> > [...]
> >> One of the goal was to add a second hierarchical level, and to  
> >> give  more informations about why the steps are required. I  
> >> thought that the old version was a big list of steps (6) with a  
> >> lot of similarities (Register, Request, Register, Subscribe…). Not  
> >> something very attractive, and the risk is that somebody miss a  
> >> step (I did it: I skipped the step 4) is important. Registration  
> >> should be so simple that it should only take one click.
> >
> > One Click? ... I'm still dreaming about getting Single-Sign-On for  
> > all our OOo related pages. A nice dream :-)
>
> I was sure you would enjoy this idea ;)
>
> > The second hierarchy is helpful - I agree. At the moment it just  
> > feels a bit weird to have two separate steps below "First Step".  
> > Maybe we could find something better, e.g. a simple First/Second/Last?
>
> I have opted for a more literate form… Do you think it is right?

Yep, I like it - I have used it in my last proposal (6:53pm).

I'm still a bit unsure if people just read the heading, finish step
1./2. and stop reading further. Especially since the sections are
somehow separated when using <h1> style.

> >>> Same for the reworked template for UX. Example: Why is it  
> >>> necessary to add all projects in our navigation bar? Isn't less  
> >>> more at this point?
> >>
> >> I did this because I have seen that other projects (art?) did so,  
> >> And I think it is a good idea to ease the navigation between  
> >> projects.
> >
> > Mmh, I don't think that this really adds benefit. Especially since  
> > there are so many projects around: incubator projects, accepted  
> > projects, NL projects, ... And we have the "related projects"  
> > section on our website.
> > So we are wrong in any case, and it requires very much space.  
> > (Nearly all the pages on my system are now corrupted).
>
> OK, it's easy to change ;)
>
> Back to the style sheet, it is not a good idea to have text using all  
> the width of the page (especially if you have a big screen). A better  
> readability is achieved when the line width does not exceed 150 chars.
>
> Limiting the text width would provide space on the right for this  
> kind of navigation menus.
>
> Also, I plan to rework all these horrible tables that don't fit in a  
> normal screen, such as the one in the UX list of members.
>
> > My proposal would be to use the side navigation for very essential
> > pages, which itself lead to others. Maybe it's time to discuss a
> > website/wiki strategy?
>
> +1 But please note that a wiki is a tool that do not cope well with  
> "big planned work" so the strategy should be directed toward small  
> changes, incremental improvements…

You are right, that was my hope. In my opinion, the general concept
should be made available in the wiki to be worked/agreed on. Then small
"action" steps could be realized by interested people and reviewed by
others.

Just a funny side note: Today I searched for some information and found
some initial ideas how to improve the Wiki content. Some months ago I
noted, that I should ask you for writing some "welcome to UX" for new
members, because you have been complimented by a new member for you warn
words. Just be warned ;-)

> > Although this is the topic "New on the wiki!", I would like to  
> > start a discussion with you how our page could be structured. This  
> > is something I have in mind for many months, but for the sake of  
> > sickness (still...) it may not be complete. What I would like to  
> > hear is your opinion...
> >
> > Although I'm a big friend of requirements (some of them are already  
> > documented on my home PC), I will just skip them and provide the  
> > proposed result.
> >
> > === Wiki ========================================================
> >
> > I would like to propose a general structure for the main page,
> > For...: Users, Developers, UX Team
>
> Although I agree with the proposed content below, I think it is  
> better to categorize content according to the content, not the  
> reader. Let the user decide what content (s)he is looking for.

Okay, this should have been better described by me: The pages itself
should be content driven, but the uppermost navigation (the main UX wiki
page or web page) should support the different target groups. From my
experience, people (especially newcomers or people who just search for
"their" information") are really grateful for such a pre-selection.

> Also, one strength of the wiki is the possibility to add links  
> easily, so that we can focus on a page content rather than having to  
> focus on where the page fits in the hierarchy. Then we can easily  
> create pages listing other pages for special use.

If possible, as less hierarchy as possible. For some things it may make
sense (e.g. I decided to use it for the Administration part of UX), but
in general I support page categories and templates.

> >   * Users: For general users just looking around - a showcase of  
> > things we did. Or how they may contribute - e.g. by using the  
> > brainstorming blog.
> >   * Developers: May refer to things like "why UX makes sense" or  
> > "how to get UX involved"
> >   * UX Team: This section may contain our project administration  
> > (decisions, communication) which do already exist. And it could  
> > contain things like literature, resources or best practices for the  
> > Wiki (see below).
>
> In my opinion, for the UX team, the wiki should be mainly a knowledge  
> base. Developers have API documentation and sources, Users have user  
> documentation, but UX team members still need some dedicated  
> documentation.

I don't understand that, what do you mean with dedicated documentation?
All I know is, that we don't really have own information - we don't even
have simple UI guidelines. That should be changed, especially withing
the Renaissance activities.


> > New Content/Improvements:
> >   * An overall view on what we do and how we do it (Where do the  
> > problem requests come from, e.g. Issue Tracker or ux-request? What  
> > is the basis for our decisions, e.g. data from survey,  
> > experience, ...?)
> >   * Description of Tools like the Wiki and Software (e.g. what do  
> > we use when we want to archive xyz)
> >   * As already proposed: Best practices for working with the wiki...
> >   * Explanation of common myths about User Experience and Usability  
> > to better understand what we are and what not (some of them already  
> > collected)
> >   * More resources and literature --> e.g. merge the ones from the  
> > Renaissance page and the current UX page
> >
> > According to the first topic "overall view", I would like to have
> > something which we could all use for reference: e.g. how we relate  
> > to the specs project, what if there is no i-Team, ... And the  
> > others could see where we add benefit in the development process.
> >
> > === Website ux.openoffice.org ==================================
> >
> > This page is still required for administration, so we need some  
> > entry point. What I would like to do is:
> >   * Remove some of the unnecessary links (e.g. Yahoo Pipes, CVS,  
> > Documents, ...)
> >   * Keep it just as a placeholder - only use the Wiki for  
> > developing content (so that everybody is able to participate)
> >   * The main reason for the page would be to contain a "Go to the  
> > Wiki, because we work there"-button.
> >   * Harmonize the Quick-Links with the ones in the wiki
> >   * Maybe we can add a nice logo-graphic which better serves the  
> > part "Experience"
>
> +1 to all the above concerning the ux.openoffice.org website.  
> Concerning the logo, we should not have only one ;) But we could  
> improve it. For example, I think that using a font such as Museo  
> would be better, but it is another subject.

Ouch, that is a delicate (separate) topic, because this is related to
marketing - like building a "stable" brand inside the OOo community. The
logo, the slogans, the email signatures are all part of it [1]. It
caused weeks of discussion and the logo has been finally been created by
Christian (who has a degree in design) - professional font (OOo
project), simple, clean, re-usable.

[1]
http://wiki.services.openoffice.org/wiki/User_Experience/Project_Strategy/External_Communication

> > === Mailing Lists ===============================================
> >
> > Concerning our mailing lists, I would like to improve their  
> > description (as Graham pointed out in early December)
>
> +1
>
> > and remove the unused ones (dependent on what we decide for the  
> > Issue Tracker, maybe we will need ux-issues in the future).
>
> +1

I'm glad that you support so many of my proposals. I hope we can soon
get a roadmap how to proceed in the wiki.

And by the way, I would like to re-easify the navigation panes in the
wiki templates - as Frank also pointed out. My proposal which (I hope)
makes the best out of your and my input:
      * Project
              * User Experience Project Home
              * User Experience Wiki Home
      * Communication
              * User Experience Mailing Lists
              * User Experience Wiki Category
              * User Experience Team Blog
      * Team
              * User Experience Team
              * How to Join?

Okay?


> Clément, a little bit overworked ;)

I hope you will have a refreshing sleep! Bye,

Christoph,


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Graham Perrin
Administrator
In reply to this post by Christoph Noack
Christoph Noack wrote
> … 4. direction from Bugzilla, to discuss@ux

Okay, up to this point, we don't have any influence - if we didn't caused the bug ;-)
Sure ;-)

(1) through (4) were background points explaining my tendency to discuss mostly in a tracker.

… Personally, I don't like to enforce a membership for people who just have a question. That does not make sense, especially since CollabNet is not a real help here. The membership is targeted at people who are generally interested in UX. And to better support them, we do ask for so much background information.
Today I recognise the word 'CollabNet' in the same way that a few weeks ago I recognised the word 'EIS'.

I see the word here and there but I have no idea what CollabNet is, whether its origins are with Sun or with previous developers of StarOffice, whether it extends beyond OOo, etc..

I will look into it :) you need not explain to me, but in my discussions with the two lists I have zero sense of using CollabNet. I assume that it's not essential to know what CollabNet is.

… if messages are sent to the list without being subscribed …
I should not expect to post without subscription, I always expect to subscribe.

I am more accustomed to lists/fora being the primary (not secondary or tertiary) means of involvement with a group.

> Please, can we gently review the required order of things at 'How To Join'?

I would rather discuss how we can handle such requests like yours - the How To Join seems to have an other target group.

(And an except of your last mail which just arrived...)

> I forgot to add, the new wiki page does look much better than when I
> joined
> :)

Does it look better, or is it more helpful? If the latter, then please give us a clue why? Thanks!
Both: as appearance is improved, so meaning is better.

I first imagined that the page did not previously state "(it may take some time for your email to be answered, because it is manually administered if the steps below have not been finished)" but a review of the history proves that line appearing some months ago.

The new margin note-style icons add greatly to readability.

More than the large star: I prefer the large 'i', for information. (To me, what is starred is simply: information. How is starred information different from informative information?)

Variety of icons is comparable to an excess of heading levels.

In terms of style, I would have these icons appear more within a margin. A very quick sketch, paying attention only to the line of the text and the icons to the left of that line:



Regards
Graham
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack
Hi Graham,

sorry for just saying "CollabNet". It is the basis for the whole
OpenOffice.org project infrastructure. Have a look at the bottom of
http://www.openoffice.org 

Bye,
Christoph


Am Samstag, den 31.01.2009, 16:00 -0800 schrieb Graham Perrin:
> Today I recognise the word 'CollabNet' in the same way that a few
> weeks ago
> I recognised the word 'EIS'.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Width not exceeding 150 characters: origin, pros and cons (was: New on the wiki!)

Christoph Noack
In reply to this post by Graham Perrin
Hi Graham,

Am Samstag, den 31.01.2009, 15:12 -0800 schrieb Graham Perrin:

>
> Clément Pillias wrote:
> >
> > not a good idea to have text using all the width of the page (especially
> > if you have a big screen). A better readability is achieved when the line
> > width does not exceed 150 chars.
>
> Interesting, I find completely the opposite. I love texts that extend from
> far left to far right of my display (1650 pixels). YMMV.
>
> When I encounter a column of text that is too narrow: I often send the
> content beyond the web page, to be read more easily in some other
> application. I tend towards Tofu, in which the right arrow (not the page
> down key) scrolls smoothly to present the next screen.
>
> I don't argue for a change to whatever standard is preferred for the masses,
> but I'm curious to know the origin of the 150 character guideline.

I don't know the exact number of chars, but the reason is simple -
improve readability. The readability of magazines and newspapers have
been researched since a long time. Therefore "the good magazines" use a
certain layout with relatively narrow rows. Those rows help to keep the
line and maximize the "text input efficiency". I hope this helps...

Bye,
Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Realising why narrowness and/or multiple columns are difficult (was: Width not exceeding 150 characters: origin, pros and cons)

Graham Perrin
Administrator
Christoph Noack wrote
> … I'm curious to know the origin of the 150 character guideline.

I don't know the exact number of chars, but the reason is simple - improve readability. The readability of magazines and newspapers have been researched since a long time. Therefore "the good magazines" use a certain layout with relatively narrow rows. Those rows help to keep the line and maximize the "text input efficiency". I hope this helps...

Bye,
Christoph
Screens of computers are usually landscape. In recent years there's the tendency towards widescreen — partially driven, I suppose, by multiple uses to include widescreen movies.

Printed media still tend towards portrait, and I never appreciated the rows/columns thing in newspapers and magazines, all of which got me wondering …



Since early childhood (1960s/1970s) I have found narrow texts, in particular side-by-side columns of text, more difficult to read than single column full width text.

What was true for me thirty-odd years ago remains true now. After much foraging through A4 magazines scattered around the flat, I eventually found some full-width print. Elsewhere in the same publication: full-width text in the top half of the page, four columns in the lower half. Sure enough: it takes me maybe twice as long to read the columnised text.

I now realise that my tendency is to skip/ignore the vast majority of narrow/columnised text and look instead at:

* the pictures
* any full-width text.

Why are columns/narrowness more difficult for me? Not related to a problem with eyesight. Maybe associated with dyslexia? I thought of the coloured filter approach for dyslexics, which I never tried (the dyslexia wasn't drawn to my attention until the mid-1990s).

Then, I recalled some very old spectacles that I had made up in the 1980s. With … green lenses. This morning I dusted off those spectacles and sure enough, the four columns become easier to read :)

It's not the (very weak) prescription of lens alone that eases the reading; it's the tint.

Back in the 1980s, all I knew was that I liked green-tinted lenses.

Now, suddenly, I realise *why* I had that preference!

Things fall into place. The last time I bothered to have spectacles made up, four or five years ago, again I opted for a green tint. (A five-minute wonder, I lost them, probably on top of the car when filling up at the petrol station, typically dizzy behaviour!)

Clément, Christoph and all: special thanks — without the thought-provoker and disagreement (YMMV) about columns/widths/layouts, I might never have made these connections :)

There's a follow-on from this, but it belongs in a different thread …

Cheers
Graham
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki!

Clément Pillias
In reply to this post by Christoph Noack
Hi Christoph!

Le 31 janv. 09 à 18:53, Christoph Noack a écrit :

> Am Samstag, den 31.01.2009, 13:26 +0100 schrieb Clément Pillias:
>>> Le 31 janv. 09 à 07:23, Philip Ganchev a écrit :
>>>
>>>> In all versions, I don't like the verbosity - it is an  
>>>> unnecessary hurdle. For example, sentences like "Great! It seems  
>>>> that you have gone through the steps successfully. So what are  
>>>> your options now?" should be omitted. They try to sound  
>>>> friendly, but actually   just waste time. The friendly thing is  
>>>> to be concise and clear.
>>
>> I have done a few changes in that direction.
>
> Philip, I added such text because some people do really want to be
> guided - that was also the reason for adding an introduction where
> people might find further information about UX.

People like to be guided, but they really dislike to be guided with  
too much verbosity… remember C3PO explaining why the millenary falcon  
hyperspace propulsion does not work? ;)

So I think that work has to be done on the wording… Maybe Liz could  
give some hints when she has time.

> Other people might simply skip this information, therefore I  
> focused on (visually) separating essential and additional  
> information. Therefore the old structure [1] has been:
>
>         Step X: Title (bold)
>         Short explanation what will be done at [link].
>         Explanatory text for newcomers... (italic)
>
> As a consequence, people who are familiar with OOo or OSS in  
> general could just read the titles and click on the links. Other  
> people, e.g. newcomers, who may require more information may read  
> the italic explanations. This structure is similar to our recent  
> discussions how dialogs work. And, due to the step numbers, I hoped  
> that people can easily see that there is more to come...

I agree that it is a good idea to maintain consistency and to have a  
clear structure, but here it seems inappropriate to me since some  
"explanatory text for newcomers" is introduction, some of it is  
explanation, some of it is tips for people already registered, some  
of it gives other possible actions (such as getting help)…

So it is more something like forcing content into a fixed structure  
than getting an efficient structure according to the content and its  
usage.

> And now?
>
> Each of the three main sections is structured differently, which  
> makes it really necessary to read all the text to interpret the  
> information - here I think we lost efficiency.

Actually, only the first section has a different structure. I  
initially planed to use the same structure (two second level titles,  
introduction and explicative text ending with the action link,  
eventually complementary text), but I found that we could reduce and  
simplify a lot the section. I plan to test some change to increase  
consistency between sections, so stay tuned :)

> Mmh, never criticize something if you don't have an alternative :-)  
> Wait a second...
>
> Besides that, I noticed that the new content (headings) put a  
> stronger focus on the tooling instead of the members. For me, it  
> makes a huge difference if people read a) "Finally, Present  
> Yourself ... On the Mailing List" instead of b) "Step 6: Get in  
> Contact". The first one seems to put some burden on the new member,  
> the second one puts emphasis on the "together", the "team".
>
> So how about that?
>       * Start by Becoming a Formal Member
>               * (no sub-head
>       * Continue with Setting-Up Communication Tools
>               *
>       * Finally, Get in Touch with Us
>               * Present Yourself in the Wiki
>               * Say Hello On The Mailing List!

+1 and done :)

> And for each main category:
>       * I love to see a given structure like:
>               * (optional) Sub-Heading (H2)
>               * Short Statement(s) with [link]
>               * Explanatory text incl. alternatives
>               * (optional) Tip section

I think it is better to have explanatory text before the links, then  
the links, separated (as action links). Then eventually,  
alternatives, and finally tips.

>       * I would like to avoid re-started numberings (1., 2., ...)
>       * Avoid the style 'information', because (from my point of  
> view) all the informational text is equal on the page (otherwise we  
> might need boxes for all of that text)

I use only one information section in the latest version, and it is  
used to give help about wiki usage… I think it is a good idea to give  
this section a distinctive look, because it is really information for  
people who are not used to wikis.

>       * The content of the tip sections should be kept.
>
> Your opinion?
>
>
> What I still don't understand, why didn't we ask some of the newer
> members how they managed to get through this how-to? I know many of  
> them did not present themselves here - maybe for very different  
> reasons. It should be relatively easy to get a list of them and to  
> ask them some questions to improve our procedures.

+1

> But and the end - it is still a simple wiki page we're discussing.
> Although this page is some vCard for the project and it's work - we  
> have still two real requests on this list without any response from  
> our side (new Group for AutoCorrect options, Tab Colors in Calc).

And I did a proposition for "Issue 18748: At autocompletion TAB-key-
use no longer…" that is still without reply.

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Clément Pillias
In reply to this post by Ivan M
Hi Ivan!

Le 31 janv. 09 à 20:07, Vladimir Miskovic a écrit :

> On Sat, Jan 31, 2009 at 6:45 AM, Clément Pillias
> <[hidden email]> wrote:
>> Additionally, I am very unsatisfied by the wiki style sheet, and
>> particularly with the h3 titles being bolder than h2. It really  
>> makes structured pages hard to read.
>
> Very unsatisfied? It sounds like you have a long list :)

Not so long :)

> Please send all comments/suggestions/complaints to
> [hidden email] - alternatively, you could start a new
> thread on this list, since I am currently the maintainer of the
> OOoSkin stylesheet, and I'll announce it on website-dev.

OK I will do that… later ;)

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Clément Pillias
In reply to this post by Graham Perrin
Hi Graham!

Thank you for this very useful post.

Le 31 janv. 09 à 23:48, Graham Perrin a écrit :

> My route to discuss@ux was this:
> […]
> At that point, I found the order of things at
> <http://wiki.services.openoffice.org/wiki/User_Experience/Community/ 
> How_To_Join> surprising.
>
> I had been simply: directed to a list, for discussion, mainly in  
> relation to a single bug and its dependencies.

Maybe we should change the introduction text to highlight why, when  
and who should "join", and clearly state that "joining" is not a  
mandatory step to "contact" us. So we could (if not already done)  
create a specific page on how to contact us to participate  
occasionally (ending with a section "what next" linking to "how to  
join".)

But we must take care that the four following pages clearly state in  
what they differ and link to each other:
* User Experience/Community/How to Join
* HowTo Request User Experience Assistance
* User Experience/How to Participate
* User Experience/How to Contact Us (to be created)

Best Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Clément Pillias
In reply to this post by Christoph Noack

Le 1 févr. 09 à 00:08, Christoph Noack a écrit :

> Joining the team and subscribing to the mailing list is required by  
> the CollabNet infrastructure to post messages. Okay, if messages  
> are sent to the list without being subscribed, then the  
> administrators can accept the mail anyway. But for usual  
> discussions, yes, this is the way to go.

I just made a test, and actually it is not needed to be an  
OpenOffice.org registered contributor to subscribe to the mailing  
list. Everybody can do it: simply send an empty message to discuss-
[hidden email]

It does not even seem to be moderated.

But registration is needed for writing in the wiki, so the steps in  
"How to Join" are still useful.

>> Please, can we gently review the required order of things at 'How  
>> To Join'?
>
> I would rather discuss how we can handle such requests like yours -  
> the How To Join seems to have an other target group.

See my reply to Graham…

Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Clément Pillias
In reply to this post by Christoph Noack

Le 1 févr. 09 à 00:55, Christoph Noack a écrit :

> I'm still a bit unsure if people just read the heading, finish step  
> 1./2. and stop reading further. Especially since the sections are  
> somehow separated when using <h1> style.

Actually, I intentionally increased the spacing between sections.  
There is too much spacing now, but there would not have been enough  
otherwise :(

>> In my opinion, for the UX team, the wiki should be mainly a  
>> knowledge base. Developers have API documentation and sources,  
>> Users have user documentation, but UX team members still need some  
>> dedicated documentation.
>
> I don't understand that, what do you mean with dedicated  
> documentation?
> All I know is, that we don't really have own information - we don't  
> even have simple UI guidelines. That should be changed, especially  
> within the Renaissance activities.

Everybody recognizes the need to get more knowledge about our users,  
and how they use the product. This is one of the goals of Renaissance.

Personas, Survey results, etc. describe our users, and are part of  
the informations needed by the User Experience team to work (although  
this information is not specific to UX: it could also be useful to  
Marketing).

Concerning the use of the product, we will have data from the  
extension recording UI events, and maybe data from experiments  
(observing real users). This kind of information has only little  
interest outside the User Experience team.

And finally, there is information about the product itself.  
Currently, when discussing issues, I often asks myself "How does OOo  
reacts when the user does this or that?" and I have to open OOo and  
test, because neither the User Documentation neither the developers  
APIs or sources offer help. Although it may contain the information I  
am looking for, it is not organized in a way that is useful for me:  
behavior of some GUI object is described in many places according to  
the logic of the application, or according to the kind of task it  
supports and the expertise level required. But what I need is an  
overview of all possible interactions using that element.

That is why I feel the need for pages dedicated to some GUI elements  
such as the Zoom Slider [1] or the StartCenter [2], or the page  
listing Calc's Cell Edition modes [3]. We could even formalize this  
practice and create templates for GUI elements and modes.

Finally, I had an idea in this direction, related to the recent  
request for contextual inquiry by non-Sun members in the Renaissance  
project. This kind of work seems hard to do without enough structure,  
but the community could easily give information at the interface of  
"How the user uses the application" and "How the application works".

E.g. by listing what I call "Interaction patterns": a small  
description in a few steps of some interaction believed to be often  
done by real users. Such as "Selecting a whole paragraph",  
"displacing a whole table in Calc from one sheet to another", etc. If  
these "interaction patterns" are sufficiently well described, we  
could use the feedback extension to actually measure how often they  
are effectively used. And if different alternative exist, know what  
alternative is preferred.


[1] http://wiki.services.openoffice.org/wiki/Zoom_Slider

[2] http://wiki.services.openoffice.org/wiki/User_Experience/StartCenter

[3] http://wiki.services.openoffice.org/wiki/Calc/Cell_Edition_Modes

> And by the way, I would like to re-easify the navigation panes in  
> the wiki templates - as Frank also pointed out. My proposal which  
> (I hope) makes the best out of your and my input:
>       * Project
>               * User Experience Project Home
>               * User Experience Wiki Home
>       * Communication
>               * User Experience Mailing Lists
>               * User Experience Wiki Category
>               * User Experience Team Blog
>       * Team
>               * User Experience Team
>               * How to Join?

This may help non-UX members, but I think it lacks tools dedicated to  
UX members: I use a lot the "User Experience Wiki Category" and I  
added the mailing lists because I lost a lot of time looking for it  
each time I wanted to find the URL for a message. Also, "How to  
participate?" could be a good candidate for inclusion in the template.

Best Regards,

Clément.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack-3
In reply to this post by Clément Pillias
Hi Clément,

I'm back!

Am Sonntag, den 01.02.2009, 14:36 +0100 schrieb Clément Pillias:

> Le 1 févr. 09 à 00:08, Christoph Noack a écrit :
>
> > Joining the team and subscribing to the mailing list is required by  
> > the CollabNet infrastructure to post messages. Okay, if messages  
> > are sent to the list without being subscribed, then the  
> > administrators can accept the mail anyway. But for usual  
> > discussions, yes, this is the way to go.
>
> I just made a test, and actually it is not needed to be an  
> OpenOffice.org registered contributor to subscribe to the mailing  
> list. Everybody can do it: simply send an empty message to discuss-
> [hidden email]
>
> It does not even seem to be moderated.

Thanks for testing that - I was not aware of the fact that the list
management is separated from the member management. That might be
solution for many people like Graham, who just want to ask some things.

Maybe it will make things harder, because people are a little bit more
anonymous - but will change automatically ;-)

Thank you,
Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki!

Christoph Noack
In reply to this post by Clément Pillias
Hi Clément!

Am Sonntag, den 01.02.2009, 14:17 +0100 schrieb Clément Pillias:

> Hi Christoph!
>
> Le 31 janv. 09 à 18:53, Christoph Noack a écrit :
>
> > Am Samstag, den 31.01.2009, 13:26 +0100 schrieb Clément Pillias:
> >>> Le 31 janv. 09 à 07:23, Philip Ganchev a écrit :
> >>>
> >>>> In all versions, I don't like the verbosity - it is an  
> >>>> unnecessary hurdle. For example, sentences like "Great! It seems  
> >>>> that you have gone through the steps successfully. So what are  
> >>>> your options now?" should be omitted. They try to sound  
> >>>> friendly, but actually   just waste time. The friendly thing is  
> >>>> to be concise and clear.
> >>
> >> I have done a few changes in that direction.
> >
> > Philip, I added such text because some people do really want to be
> > guided - that was also the reason for adding an introduction where
> > people might find further information about UX.
>
> People like to be guided, but they really dislike to be guided with  
> too much verbosity… remember C3PO explaining why the millenary falcon  
> hyperspace propulsion does not work? ;)

Let's say it this way: This is something which really depends on
subjective preferences - maybe some people would have liked to hear more
from C3PO. But at this point I'm open for proposals - I just want to
avoid the millenium falcon talk only 0101011 - a bit too short ;-)

> So I think that work has to be done on the wording… Maybe Liz could  
> give some hints when she has time.
>
> > Other people might simply skip this information, therefore I  
> > focused on (visually) separating essential and additional  
> > information. Therefore the old structure [1] has been:
> >
> >         Step X: Title (bold)
> >         Short explanation what will be done at [link].
> >         Explanatory text for newcomers... (italic)
> >
> > As a consequence, people who are familiar with OOo or OSS in  
> > general could just read the titles and click on the links. Other  
> > people, e.g. newcomers, who may require more information may read  
> > the italic explanations. This structure is similar to our recent  
> > discussions how dialogs work. And, due to the step numbers, I hoped  
> > that people can easily see that there is more to come...
>
> I agree that it is a good idea to maintain consistency and to have a  
> clear structure, but here it seems inappropriate to me since some  
> "explanatory text for newcomers" is introduction, some of it is  
> explanation, some of it is tips for people already registered, some  
> of it gives other possible actions (such as getting help)…
>
> So it is more something like forcing content into a fixed structure  
> than getting an efficient structure according to the content and its  
> usage.

Mmh, really? If there is additional information which makes sense before
and after some core statement, why should it be wrong to maintain a
fixed structure? Maybe I was wrong when I simply refereed to it as
"explanatory text for newcomers", remove the "newcomers" and it still
feels good - in my opinion.

But before you put the label "no-say" on me, I'm really happy about the
current outcome of our discussions. Now it feels friendly and complete -
without distracting with too much color. Thanks!

[...]

> > So how about that?
> >       * Start by Becoming a Formal Member
> >               * (no sub-head
> >       * Continue with Setting-Up Communication Tools
> >               *
> >       * Finally, Get in Touch with Us
> >               * Present Yourself in the Wiki
> >               * Say Hello On The Mailing List!
>
> +1 and done :)

Thanks!

> > And for each main category:
> >       * I love to see a given structure like:
> >               * (optional) Sub-Heading (H2)
> >               * Short Statement(s) with [link]
> >               * Explanatory text incl. alternatives
> >               * (optional) Tip section
>
> I think it is better to have explanatory text before the links, then  
> the links, separated (as action links). Then eventually,  
> alternatives, and finally tips.

Okay - as you said - I stay tuned ;-)

[...]
> > What I still don't understand, why didn't we ask some of the newer
> > members how they managed to get through this how-to? I know many of  
> > them did not present themselves here - maybe for very different  
> > reasons. It should be relatively easy to get a list of them and to  
> > ask them some questions to improve our procedures.
>
> +1

Proposal: Just tell me when your site re-design is finished. Then we
might ask five new members to get their opinion concerning problems they
encoutered...


Okay, thank you Clément for being so open!

Christoph


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Realising why narrowness and/or multiple columns are difficult (was: Width not exceeding 150 characters: origin, pros and cons)

Christoph Noack
In reply to this post by Graham Perrin
Hi Graham,

I've read your mail with great interest - I've never heard of such a
treatment before. So just a big thank you for providing us some
'insight'.

Bye,
Christoph

Am Sonntag, den 01.02.2009, 00:17 -0800 schrieb Graham Perrin:

>
> Christoph Noack wrote:
> >
> >> … I'm curious to know the origin of the 150 character guideline.
> >
> > I don't know the exact number of chars, but the reason is simple - improve
> > readability. The readability of magazines and newspapers have been
> > researched since a long time. Therefore "the good magazines" use a certain
> > layout with relatively narrow rows. Those rows help to keep the line and
> > maximize the "text input efficiency". I hope this helps...
> >
> > Bye,
> > Christoph
> >
>
> Screens of computers are usually landscape. In recent years there's the
> tendency towards widescreen — partially driven, I suppose, by multiple uses
> to include widescreen movies.
>
> Printed media still tend towards portrait, and I never appreciated the
> rows/columns thing in newspapers and magazines, all of which got me
> wondering …
>
> —
>
> Since early childhood (1960s/1970s) I have found narrow texts, in particular
> side-by-side columns of text, more difficult to read than single column full
> width text.
>
> What was true for me thirty-odd years ago remains true now. After much
> foraging through A4 magazines scattered around the flat, I eventually found
> some full-width print. Elsewhere in the same publication: full-width text in
> the top half of the page, four columns in the lower half. Sure enough: it
> takes me maybe twice as long to read the columnised text.
>
> I now realise that my tendency is to skip/ignore the vast majority of
> narrow/columnised text and look instead at:
>
> * the pictures
> * any full-width text.
>
> Why are columns/narrowness more difficult for me? Not related to a problem
> with eyesight. Maybe associated with dyslexia? I thought of the coloured
> filter approach for dyslexics, which I never tried (the dyslexia wasn't
> drawn to my attention until the mid-1990s).
>
> Then, I recalled some very old spectacles that I had made up in the 1980s.
> With … green lenses. This morning I dusted off those spectacles and sure
> enough, the four columns become easier to read :)
>
> It's not the (very weak) prescription of lens alone that eases the reading;
> it's the tint.
>
> Back in the 1980s, all I knew was that I liked green-tinted lenses.
>
> Now, suddenly, I realise *why* I had that preference!
>
> Things fall into place. The last time I bothered to have spectacles made up,
> four or five years ago, again I opted for a green tint. (A five-minute
> wonder, I lost them, probably on top of the car when filling up at the
> petrol station, typically dizzy behaviour!)
>
> Clément, Christoph and all: special thanks — without the thought-provoker
> and disagreement (YMMV) about columns/widths/layouts, I might never have
> made these connections :)
>
> There's a follow-on from this, but it belongs in a different thread …
>
> Cheers
> Graham


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

CollabNet not helping to find User Experience Project content (not helping to improve the web presence)

Graham Perrin
Administrator
In reply to this post by Christoph Noack
Christoph Noack wrote
… "CollabNet". It is the basis for the whole OpenOffice.org project infrastructure. Have a look at the bottom of http://www.openoffice.org 
Ah :)

I vaguely recognise the word CollabNet from <http://subversion.tigris.org/>, not from <http://www.openoffice.org/>. Probably because in the openoffice.org domain there's usually so much going on, the footer is the last place I look.

I filed two defect issues this morning,

• Advanced search of entire openoffice.org domain fails to find wiki content

• User Experience wiki lacks a search interface
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Elizabeth Matthis
In reply to this post by Christoph Noack
Hi Christoph,
Hi Clément,
Hello All,
 
I've read this discussion and am impressed by your knowledge (as usual
;-) ) and dedication to improving the wiki and want to thank you both
for making our little UX world a better place. I'm so glad that you have
made the pages better so everyone can benefit. I wish I were as fast as you!

My wiki uasge survey was stalled because I was helping the team with the
other surveys (e.g. User Survey 2009, IsoMetrics), but I'm finishing it
up and look forward to getting quality feedback from lots of people
across OOo.

I was especially interested in your complaints about the documentation
template and the lack of general guidelines (aside from the
documentation ones). You have probably seen this page:
http://wiki.services.openoffice.org/wiki/User_Experience/SOP
It was written by Leonard Mada, who may or may not still be active on
this list. I don't recall any messages from him since I started back in
October 2008. At any rate, he wrote this very concise SOP and it could
be a good place to start with more guidelines or rewrite the existing
ones or structure the clean-up work, for example see his clean up
suggestion:
http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/Cleanup

I hesitate to ask anyone to come up with general OOo wiki guidelines
(pick and choose from documentation guidelines and others to create
every-day guidelines to offer everyone to use? And not only for the UX
pages!) right now, because I want to await the results of my wiki usage
survey to utilize the input in the guidelines, but you two are already
so active I thought I'd mention the subject of guidelines coming in the
near future. Cleaning up and improving is past present and future,
though, so more power to you!

Thanks again for all the good stuff you've put into the UX wiki pages!
Liz
p.s. SOP = "Standard Operating Procedures" It sounds very impressive and
a bit daunting for non-techies who may be interested in UX pages, so I
suggest using a different title, but that is up to the editor(s). I say:
"Doers can be choosers" (in contrast to "Beggars can't be choosers") ;-)


On 01.02.09 00:55, Christoph Noack wrote:

> Good evening Clément!
>
> Am Samstag, den 31.01.2009, 14:11 +0100 schrieb Clément Pillias:
>  
>> Le 30 janv. 09 à 23:31, Christoph Noack a écrit :
>>    
>
>  
>>> [...]
>>>      
>>>> One of the goal was to add a second hierarchical level, and to  
>>>> give  more informations about why the steps are required. I  
>>>> thought that the old version was a big list of steps (6) with a  
>>>> lot of similarities (Register, Request, Register, Subscribe…). Not  
>>>> something very attractive, and the risk is that somebody miss a  
>>>> step (I did it: I skipped the step 4) is important. Registration  
>>>> should be so simple that it should only take one click.
>>>>        
>>> One Click? ... I'm still dreaming about getting Single-Sign-On for  
>>> all our OOo related pages. A nice dream :-)
>>>      
>> I was sure you would enjoy this idea ;)
>>
>>    
>>> The second hierarchy is helpful - I agree. At the moment it just  
>>> feels a bit weird to have two separate steps below "First Step".  
>>> Maybe we could find something better, e.g. a simple First/Second/Last?
>>>      
>> I have opted for a more literate form… Do you think it is right?
>>    
>
> Yep, I like it - I have used it in my last proposal (6:53pm).
>
> I'm still a bit unsure if people just read the heading, finish step
> 1./2. and stop reading further. Especially since the sections are
> somehow separated when using <h1> style.
>
>  
>>>>> Same for the reworked template for UX. Example: Why is it  
>>>>> necessary to add all projects in our navigation bar? Isn't less  
>>>>> more at this point?
>>>>>          
>>>> I did this because I have seen that other projects (art?) did so,  
>>>> And I think it is a good idea to ease the navigation between  
>>>> projects.
>>>>        
>>> Mmh, I don't think that this really adds benefit. Especially since  
>>> there are so many projects around: incubator projects, accepted  
>>> projects, NL projects, ... And we have the "related projects"  
>>> section on our website.
>>> So we are wrong in any case, and it requires very much space.  
>>> (Nearly all the pages on my system are now corrupted).
>>>      
>> OK, it's easy to change ;)
>>
>> Back to the style sheet, it is not a good idea to have text using all  
>> the width of the page (especially if you have a big screen). A better  
>> readability is achieved when the line width does not exceed 150 chars.
>>
>> Limiting the text width would provide space on the right for this  
>> kind of navigation menus.
>>
>> Also, I plan to rework all these horrible tables that don't fit in a  
>> normal screen, such as the one in the UX list of members.
>>
>>    
>>> My proposal would be to use the side navigation for very essential
>>> pages, which itself lead to others. Maybe it's time to discuss a
>>> website/wiki strategy?
>>>      
>> +1 But please note that a wiki is a tool that do not cope well with  
>> "big planned work" so the strategy should be directed toward small  
>> changes, incremental improvements…
>>    
>
> You are right, that was my hope. In my opinion, the general concept
> should be made available in the wiki to be worked/agreed on. Then small
> "action" steps could be realized by interested people and reviewed by
> others.
>
> Just a funny side note: Today I searched for some information and found
> some initial ideas how to improve the Wiki content. Some months ago I
> noted, that I should ask you for writing some "welcome to UX" for new
> members, because you have been complimented by a new member for you warn
> words. Just be warned ;-)
>
>  
>>> Although this is the topic "New on the wiki!", I would like to  
>>> start a discussion with you how our page could be structured. This  
>>> is something I have in mind for many months, but for the sake of  
>>> sickness (still...) it may not be complete. What I would like to  
>>> hear is your opinion...
>>>
>>> Although I'm a big friend of requirements (some of them are already  
>>> documented on my home PC), I will just skip them and provide the  
>>> proposed result.
>>>
>>> === Wiki ========================================================
>>>
>>> I would like to propose a general structure for the main page,
>>> For...: Users, Developers, UX Team
>>>      
>> Although I agree with the proposed content below, I think it is  
>> better to categorize content according to the content, not the  
>> reader. Let the user decide what content (s)he is looking for.
>>    
>
> Okay, this should have been better described by me: The pages itself
> should be content driven, but the uppermost navigation (the main UX wiki
> page or web page) should support the different target groups. From my
> experience, people (especially newcomers or people who just search for
> "their" information") are really grateful for such a pre-selection.
>
>  
>> Also, one strength of the wiki is the possibility to add links  
>> easily, so that we can focus on a page content rather than having to  
>> focus on where the page fits in the hierarchy. Then we can easily  
>> create pages listing other pages for special use.
>>    
>
> If possible, as less hierarchy as possible. For some things it may make
> sense (e.g. I decided to use it for the Administration part of UX), but
> in general I support page categories and templates.
>
>  
>>>   * Users: For general users just looking around - a showcase of  
>>> things we did. Or how they may contribute - e.g. by using the  
>>> brainstorming blog.
>>>   * Developers: May refer to things like "why UX makes sense" or  
>>> "how to get UX involved"
>>>   * UX Team: This section may contain our project administration  
>>> (decisions, communication) which do already exist. And it could  
>>> contain things like literature, resources or best practices for the  
>>> Wiki (see below).
>>>      
>> In my opinion, for the UX team, the wiki should be mainly a knowledge  
>> base. Developers have API documentation and sources, Users have user  
>> documentation, but UX team members still need some dedicated  
>> documentation.
>>    
>
> I don't understand that, what do you mean with dedicated documentation?
> All I know is, that we don't really have own information - we don't even
> have simple UI guidelines. That should be changed, especially withing
> the Renaissance activities.
>
>
>  
>>> New Content/Improvements:
>>>   * An overall view on what we do and how we do it (Where do the  
>>> problem requests come from, e.g. Issue Tracker or ux-request? What  
>>> is the basis for our decisions, e.g. data from survey,  
>>> experience, ...?)
>>>   * Description of Tools like the Wiki and Software (e.g. what do  
>>> we use when we want to archive xyz)
>>>   * As already proposed: Best practices for working with the wiki...
>>>   * Explanation of common myths about User Experience and Usability  
>>> to better understand what we are and what not (some of them already  
>>> collected)
>>>   * More resources and literature --> e.g. merge the ones from the  
>>> Renaissance page and the current UX page
>>>
>>> According to the first topic "overall view", I would like to have
>>> something which we could all use for reference: e.g. how we relate  
>>> to the specs project, what if there is no i-Team, ... And the  
>>> others could see where we add benefit in the development process.
>>>
>>> === Website ux.openoffice.org ==================================
>>>
>>> This page is still required for administration, so we need some  
>>> entry point. What I would like to do is:
>>>   * Remove some of the unnecessary links (e.g. Yahoo Pipes, CVS,  
>>> Documents, ...)
>>>   * Keep it just as a placeholder - only use the Wiki for  
>>> developing content (so that everybody is able to participate)
>>>   * The main reason for the page would be to contain a "Go to the  
>>> Wiki, because we work there"-button.
>>>   * Harmonize the Quick-Links with the ones in the wiki
>>>   * Maybe we can add a nice logo-graphic which better serves the  
>>> part "Experience"
>>>      
>> +1 to all the above concerning the ux.openoffice.org website.  
>> Concerning the logo, we should not have only one ;) But we could  
>> improve it. For example, I think that using a font such as Museo  
>> would be better, but it is another subject.
>>    
>
> Ouch, that is a delicate (separate) topic, because this is related to
> marketing - like building a "stable" brand inside the OOo community. The
> logo, the slogans, the email signatures are all part of it [1]. It
> caused weeks of discussion and the logo has been finally been created by
> Christian (who has a degree in design) - professional font (OOo
> project), simple, clean, re-usable.
>
> [1]
> http://wiki.services.openoffice.org/wiki/User_Experience/Project_Strategy/External_Communication
>
>  
>>> === Mailing Lists ===============================================
>>>
>>> Concerning our mailing lists, I would like to improve their  
>>> description (as Graham pointed out in early December)
>>>      
>> +1
>>
>>    
>>> and remove the unused ones (dependent on what we decide for the  
>>> Issue Tracker, maybe we will need ux-issues in the future).
>>>      
>> +1
>>    
>
> I'm glad that you support so many of my proposals. I hope we can soon
> get a roadmap how to proceed in the wiki.
>
> And by the way, I would like to re-easify the navigation panes in the
> wiki templates - as Frank also pointed out. My proposal which (I hope)
> makes the best out of your and my input:
>       * Project
>               * User Experience Project Home
>               * User Experience Wiki Home
>       * Communication
>               * User Experience Mailing Lists
>               * User Experience Wiki Category
>               * User Experience Team Blog
>       * Team
>               * User Experience Team
>               * How to Join?
>
> Okay?
>
>
>  
>> Clément, a little bit overworked ;)
>>    
>
> I hope you will have a refreshing sleep! Bye,
>
> Christoph,
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

--
Sun Microsystems GmbH                Elizabeth Matthis
Nagelsweg 55                         User Experience Engineer
20097 Hamburg                        Phone: (+49 40)23646 889
Germany                              Fax:   (+49 40)23646 550
http://www.sun.com                   mailto:[hidden email]

Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack
Hi Liz, hi Clément and all the others!

Thank you very much for bringing this up again, because those guidelines
could be very helpful!

Am Mittwoch, den 04.02.2009, 22:13 +0100 schrieb Elizabeth Matthis:
> My wiki uasge survey was stalled because I was helping the team with the
> other surveys (e.g. User Survey 2009, IsoMetrics), but I'm finishing it
> up and look forward to getting quality feedback from lots of people
> across OOo.

I'm very much looking forward concerning the wiki usage survey. I hope
this information could be used to focus on the improvement of our
pages... And, with that message my bad conscience (because of the
currently "stalled" UX wiki improvement) is somehow eased ;-)

> I was especially interested in your complaints about the documentation
> template and the lack of general guidelines (aside from the
> documentation ones). You have probably seen this page:
> http://wiki.services.openoffice.org/wiki/User_Experience/SOP
> It was written by Leonard Mada, who may or may not still be active on
> this list. I don't recall any messages from him since I started back in
> October 2008. At any rate, he wrote this very concise SOP and it could
> be a good place to start with more guidelines or rewrite the existing
> ones or structure the clean-up work, for example see his clean up
> suggestion:
> http://wiki.services.openoffice.org/wiki/User_Experience/SOP/Wiki/Cleanup

Sadly, I currently don't know about Leonard, but I agree that his pages
were one step in the right direction. There have been many discussions
about the so-called SOPs, but I do remember that many people wished a
rather "relaxed" tone of the pages.

> I hesitate to ask anyone to come up with general OOo wiki guidelines
[...]
> Thanks again for all the good stuff you've put into the UX wiki pages!

Thanks to all the people who improved the wiki in the last time. There
were some contributions I've never had (or took) the chance to say that.

> p.s. SOP = "Standard Operating Procedures" It sounds very impressive and
> a bit daunting for non-techies who may be interested in UX pages, so I
> suggest using a different title, but that is up to the editor(s). I say:
> "Doers can be choosers" (in contrast to "Beggars can't be choosers") ;-)

Although I'm a No-Doer at the moment, my favorite is still "UX Wiki Best
Practices".

But what do the others think, would one wiki page be enough
incorporating the following information?
      * Working with the Wiki
              * Creating a New Wiki Page
              * Editing an Existing Wiki Page
              * Choosing Wiki Page Names
              * Signing Wiki Pages (Categories)
              * Moving Wiki Pages
              * Deleting Wiki Pages
      * Further Tips and Hints


That's it for now! Liz, thank you again for bringing up that topic. I'm
very much interested in your survey results, so I would like to ask you
to let us know if there is something new!

Bye,
Christoph

> On 01.02.09 00:55, Christoph Noack wrote:
> > Good evening Clément!
> >
> > Am Samstag, den 31.01.2009, 14:11 +0100 schrieb Clément Pillias:
> >  
> >> Le 30 janv. 09 à 23:31, Christoph Noack a écrit :
> >>    
> >
> >  
> >>> [...]
> >>>      
> >>>> One of the goal was to add a second hierarchical level, and to  
> >>>> give  more informations about why the steps are required. I  
> >>>> thought that the old version was a big list of steps (6) with a  
> >>>> lot of similarities (Register, Request, Register, Subscribe…). Not  
> >>>> something very attractive, and the risk is that somebody miss a  
> >>>> step (I did it: I skipped the step 4) is important. Registration  
> >>>> should be so simple that it should only take one click.
> >>>>        
> >>> One Click? ... I'm still dreaming about getting Single-Sign-On for  
> >>> all our OOo related pages. A nice dream :-)
> >>>      
> >> I was sure you would enjoy this idea ;)
> >>
> >>    
> >>> The second hierarchy is helpful - I agree. At the moment it just  
> >>> feels a bit weird to have two separate steps below "First Step".  
> >>> Maybe we could find something better, e.g. a simple First/Second/Last?
> >>>      
> >> I have opted for a more literate form… Do you think it is right?
> >>    
> >
> > Yep, I like it - I have used it in my last proposal (6:53pm).
> >
> > I'm still a bit unsure if people just read the heading, finish step
> > 1./2. and stop reading further. Especially since the sections are
> > somehow separated when using <h1> style.
> >
> >  
> >>>>> Same for the reworked template for UX. Example: Why is it  
> >>>>> necessary to add all projects in our navigation bar? Isn't less  
> >>>>> more at this point?
> >>>>>          
> >>>> I did this because I have seen that other projects (art?) did so,  
> >>>> And I think it is a good idea to ease the navigation between  
> >>>> projects.
> >>>>        
> >>> Mmh, I don't think that this really adds benefit. Especially since  
> >>> there are so many projects around: incubator projects, accepted  
> >>> projects, NL projects, ... And we have the "related projects"  
> >>> section on our website.
> >>> So we are wrong in any case, and it requires very much space.  
> >>> (Nearly all the pages on my system are now corrupted).
> >>>      
> >> OK, it's easy to change ;)
> >>
> >> Back to the style sheet, it is not a good idea to have text using all  
> >> the width of the page (especially if you have a big screen). A better  
> >> readability is achieved when the line width does not exceed 150 chars.
> >>
> >> Limiting the text width would provide space on the right for this  
> >> kind of navigation menus.
> >>
> >> Also, I plan to rework all these horrible tables that don't fit in a  
> >> normal screen, such as the one in the UX list of members.
> >>
> >>    
> >>> My proposal would be to use the side navigation for very essential
> >>> pages, which itself lead to others. Maybe it's time to discuss a
> >>> website/wiki strategy?
> >>>      
> >> +1 But please note that a wiki is a tool that do not cope well with  
> >> "big planned work" so the strategy should be directed toward small  
> >> changes, incremental improvements…
> >>    
> >
> > You are right, that was my hope. In my opinion, the general concept
> > should be made available in the wiki to be worked/agreed on. Then small
> > "action" steps could be realized by interested people and reviewed by
> > others.
> >
> > Just a funny side note: Today I searched for some information and found
> > some initial ideas how to improve the Wiki content. Some months ago I
> > noted, that I should ask you for writing some "welcome to UX" for new
> > members, because you have been complimented by a new member for you warn
> > words. Just be warned ;-)
> >
> >  
> >>> Although this is the topic "New on the wiki!", I would like to  
> >>> start a discussion with you how our page could be structured. This  
> >>> is something I have in mind for many months, but for the sake of  
> >>> sickness (still...) it may not be complete. What I would like to  
> >>> hear is your opinion...
> >>>
> >>> Although I'm a big friend of requirements (some of them are already  
> >>> documented on my home PC), I will just skip them and provide the  
> >>> proposed result.
> >>>
> >>> === Wiki ========================================================
> >>>
> >>> I would like to propose a general structure for the main page,
> >>> For...: Users, Developers, UX Team
> >>>      
> >> Although I agree with the proposed content below, I think it is  
> >> better to categorize content according to the content, not the  
> >> reader. Let the user decide what content (s)he is looking for.
> >>    
> >
> > Okay, this should have been better described by me: The pages itself
> > should be content driven, but the uppermost navigation (the main UX wiki
> > page or web page) should support the different target groups. From my
> > experience, people (especially newcomers or people who just search for
> > "their" information") are really grateful for such a pre-selection.
> >
> >  
> >> Also, one strength of the wiki is the possibility to add links  
> >> easily, so that we can focus on a page content rather than having to  
> >> focus on where the page fits in the hierarchy. Then we can easily  
> >> create pages listing other pages for special use.
> >>    
> >
> > If possible, as less hierarchy as possible. For some things it may make
> > sense (e.g. I decided to use it for the Administration part of UX), but
> > in general I support page categories and templates.
> >
> >  
> >>>   * Users: For general users just looking around - a showcase of  
> >>> things we did. Or how they may contribute - e.g. by using the  
> >>> brainstorming blog.
> >>>   * Developers: May refer to things like "why UX makes sense" or  
> >>> "how to get UX involved"
> >>>   * UX Team: This section may contain our project administration  
> >>> (decisions, communication) which do already exist. And it could  
> >>> contain things like literature, resources or best practices for the  
> >>> Wiki (see below).
> >>>      
> >> In my opinion, for the UX team, the wiki should be mainly a knowledge  
> >> base. Developers have API documentation and sources, Users have user  
> >> documentation, but UX team members still need some dedicated  
> >> documentation.
> >>    
> >
> > I don't understand that, what do you mean with dedicated documentation?
> > All I know is, that we don't really have own information - we don't even
> > have simple UI guidelines. That should be changed, especially withing
> > the Renaissance activities.
> >
> >
> >  
> >>> New Content/Improvements:
> >>>   * An overall view on what we do and how we do it (Where do the  
> >>> problem requests come from, e.g. Issue Tracker or ux-request? What  
> >>> is the basis for our decisions, e.g. data from survey,  
> >>> experience, ...?)
> >>>   * Description of Tools like the Wiki and Software (e.g. what do  
> >>> we use when we want to archive xyz)
> >>>   * As already proposed: Best practices for working with the wiki...
> >>>   * Explanation of common myths about User Experience and Usability  
> >>> to better understand what we are and what not (some of them already  
> >>> collected)
> >>>   * More resources and literature --> e.g. merge the ones from the  
> >>> Renaissance page and the current UX page
> >>>
> >>> According to the first topic "overall view", I would like to have
> >>> something which we could all use for reference: e.g. how we relate  
> >>> to the specs project, what if there is no i-Team, ... And the  
> >>> others could see where we add benefit in the development process.
> >>>
> >>> === Website ux.openoffice.org ==================================
> >>>
> >>> This page is still required for administration, so we need some  
> >>> entry point. What I would like to do is:
> >>>   * Remove some of the unnecessary links (e.g. Yahoo Pipes, CVS,  
> >>> Documents, ...)
> >>>   * Keep it just as a placeholder - only use the Wiki for  
> >>> developing content (so that everybody is able to participate)
> >>>   * The main reason for the page would be to contain a "Go to the  
> >>> Wiki, because we work there"-button.
> >>>   * Harmonize the Quick-Links with the ones in the wiki
> >>>   * Maybe we can add a nice logo-graphic which better serves the  
> >>> part "Experience"
> >>>      
> >> +1 to all the above concerning the ux.openoffice.org website.  
> >> Concerning the logo, we should not have only one ;) But we could  
> >> improve it. For example, I think that using a font such as Museo  
> >> would be better, but it is another subject.
> >>    
> >
> > Ouch, that is a delicate (separate) topic, because this is related to
> > marketing - like building a "stable" brand inside the OOo community. The
> > logo, the slogans, the email signatures are all part of it [1]. It
> > caused weeks of discussion and the logo has been finally been created by
> > Christian (who has a degree in design) - professional font (OOo
> > project), simple, clean, re-usable.
> >
> > [1]
> > http://wiki.services.openoffice.org/wiki/User_Experience/Project_Strategy/External_Communication
> >
> >  
> >>> === Mailing Lists ===============================================
> >>>
> >>> Concerning our mailing lists, I would like to improve their  
> >>> description (as Graham pointed out in early December)
> >>>      
> >> +1
> >>
> >>    
> >>> and remove the unused ones (dependent on what we decide for the  
> >>> Issue Tracker, maybe we will need ux-issues in the future).
> >>>      
> >> +1
> >>    
> >
> > I'm glad that you support so many of my proposals. I hope we can soon
> > get a roadmap how to proceed in the wiki.
> >
> > And by the way, I would like to re-easify the navigation panes in the
> > wiki templates - as Frank also pointed out. My proposal which (I hope)
> > makes the best out of your and my input:
> >       * Project
> >               * User Experience Project Home
> >               * User Experience Wiki Home
> >       * Communication
> >               * User Experience Mailing Lists
> >               * User Experience Wiki Category
> >               * User Experience Team Blog
> >       * Team
> >               * User Experience Team
> >               * How to Join?
> >
> > Okay?
> >
> >
> >  
> >> Clément, a little bit overworked ;)
> >>    
> >
> > I hope you will have a refreshing sleep! Bye,
> >
> > Christoph,
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >  
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Jaron Kuppers
Hi all,

I have been following this discussion but haven't really had much to add.
So in response to Christoph's question:

On Mon, Feb 9, 2009 at 4:54 PM, Christoph Noack <
[hidden email]> wrote:

> But what do the others think, would one wiki page be enough
> incorporating the following information?
>      * Working with the Wiki
>              * Creating a New Wiki Page
>              * Editing an Existing Wiki Page
>              * Choosing Wiki Page Names
>              * Signing Wiki Pages (Categories)
>              * Moving Wiki Pages
>              * Deleting Wiki Pages
>      * Further Tips and Hints
>
>
Yes; I think one easy to find page with the great outline you suggested will
be best solution.  I could go into the benefits of a single page but I think
the convenience is well understood.

Cheers,
Jaron
Reply | Threaded
Open this post in threaded view
|

Re: New on the wiki! (And how to improve our web presence.)

Christoph Noack
Hi Jaron,

thanks for your kind reply!

Am Montag, den 09.02.2009, 17:03 -0500 schrieb Jaron Kuppers:

> Hi all,
>
> I have been following this discussion but haven't really had much to add.
> So in response to Christoph's question:
>
> On Mon, Feb 9, 2009 at 4:54 PM, Christoph Noack <
> [hidden email]> wrote:
>
> > But what do the others think, would one wiki page be enough
> > incorporating the following information? [... Proposal ...]
> >
> Yes; I think one easy to find page with the great outline you suggested will
> be best solution.  I could go into the benefits of a single page but I think
> the convenience is well understood.

Thank you for the positive feedback - I will try to start it in the next
couple of days. If anybody else wants to start ... don't hesitate ;-)

And Jaron, I did not forget your proposal to add some kind of "from idea
to implementation" [1]. This is great, I just miss any good idea how to
accomplish that description, because the procedure seems to depend on
many factors (development at Sun, freelance developer working on an
extension, ...). One starting point could be the information at the
specification project at [2].

Bye,
Christoph

[1]
http://ux.openoffice.org/servlets/ReadMsg?listName=discuss&msgNo=2882

[2] http://specs.openoffice.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

123