unity-design team mailing list archive

[James Gifford <james@xxxxxxxxxxxxxxxxx>]

Sense is correct. We should spend time submitting patches to make things
"look better", and not impose guidelines that developers will just
ignore anyway.


On 09/18/2011 03:43 PM, Sense Egbert Hofstede wrote:
> On 18 September 2011 20:11, Matthew Paul Thomas <mpt@xxxxxxxxxxxxx> wrote:
> Jonathan Meek wrote on 07/09/11 19:33:
> >>>
> >>> Actually, I intended something more in depth than that. I asked one of
> >>> the designers and am going to attempt to begin work on a comprehensive
> >>> HIG. Everything about the design needs to be thought out, not just
> >>> 'integrate with this.' The problem with this undertaking is that there
> >>> are so few applications that can be considered "Ubuntu" applications.
> >>> Less and more than you would think. (Though, I've only heard from one
> >>> person, and his design choices may not be the consensus of the entire
> >>> design team)
> >>> ...
>
> I'd hope it isn't. ;-) But Thorsten Wilms was right: what will
> developers make out of it? Interface guidelines are useless unless they
> actually change developers' behavior. For example, Microsoft has
> extensive Windows UX guidelines on MSDN, but given all the "copying
> Apple" worry in this thread, it seems nobody here has even heard of them.
>
> Now, imagine these responses from application developers if you wrote
> some interface guidelines for Ubuntu:
>
> *   "Ubuntu design guidelines? I've never heard of them."
>
> *   "Jonathan Meek? I've never heard of him. Why should I do what he
>    says?"
>
> *   "Ubuntu? Ubuntu's just a distro, what business do they have setting
>    'guidelines' for applications?"
>
> *   "I use Fedora for development, why should I care what Ubuntu wants?"
>
> *   "Ubuntu? You want me to take advice from the people who designed
>    Unity? Hah!"
>
> *   "I read a couple of pages but it was really boring."
>
> *   "Gnome already has guidelines, this is just another example of
>    Ubuntu trying to go their own way. Shame on them."
>
> Improving the design of Ubuntu applications is a design problem in
> itself. And even if those criticisms are unfair, they're going to come
> up. So if you want to make a difference, you need to have a way to
> minimize, or be able to address, each of those criticisms.
>
> >>> Provisionally, Mr. Gifford is correct. The are going to be started on,
> >>> and presented for peer review. I'm debating how to go about this now
> >>> less than I am whether to go about it at all.
> >>>
> >>> I would like some opinions to feedback into this. I know what the
> >>> designer said were good designed Ubuntu applications, but what do
> >>> people here think are some? And why do you think that? (This includes,
> >>> looks, structure, and behavior as well as integration.)
> >>> ...
>
> This is the biggie. If guidelines are to be credible, they need to be
> either self-evidently logical, demonstrated to succeed in real Ubuntu
> applications, and/or written by people who designed successful Ubuntu
> applications. The Windows, Mac, and iOS guidelines can all use
> applications designed by the OS vendor as examples of what to do. But
> there are very few applications targeted for Ubuntu first, let alone
> Ubuntu exclusively. I think guidelines will be premature until that
> changes.
>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~ayatana
>> Post to : ayatana@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help : https://help.launchpad.net/ListHelp
>>
>
> Guidelines are very great and such, but like you already said, many
> people will not even bother to read them. Even if we manage to get
> everyone to read the guidelines, then there is the issue of
> interpretation. You cannot have complete and perfect consistency if
> you don't want the guidelines to spell out the code that the
> developers have to use.
>
> We always say that we should take away the difficulty of choosing from
> users when they do not have the tools or knowledge available to make
> the right decision. The same logic applies here to developers. Most
> developers are not in the right position to make good decisions about
> interface design or about the correct implementation of a guideline.
> To do it right, we should take away their choice.
>
> That means: do not spend time implementing what we know about design
> in the text of guidelines, but spend our time implementing it in code.
> We should make GTK+ (and maybe Qt too) look better. Locate areas where
> things don't look so great and submit patches for them. Propose better
> default values for the properties, submit code that generates pretty
> menu bars, etc. We should take away choice by making the easiest
> solution available to developers the solution we want, e.g. writing
> beautiful and good implementations of standard behaviour (tabs, Ubuntu
> One, media playing, things like that) that developers can just plug
> into their applications. Because those methods will be the standard
> way of doing things, the easiest way of doing things, they will use
> them and with that they will automatically be consistent with the rest
> of the desktop.
>
> If the current solution for this problem is too hard, we should try to
> find a solution that we can handle, a solution that involves coding
> and designing under control of the right designers.
>
> Regards,

-- 
Cheers,
James Gifford
http://jamesrgifford.com

Attachment: signature.asc
Description: OpenPGP digital signature