[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libreoffice-design] Re: Revisiting our project workflow


2014-07-09 0:45 GMT+02:00 Pedro Rosmaninho <mota.prego@gmail.com>:

> That makes sense Mirek. Thanks for clearing the reasoning behind the need
> for devs!
>
> However, I would suggest creating an area where designers could share
> designs and discussions between themselves under the LO umbrella and not
> spread around Deviantart or their user pages.
> Maybe a LO design forum where designers could discuss with each others and
> maybe even get some devs to take a peek at it?
>
>
Reda suggested to use GitHub, like Gnome does [1].
There was also an effort underway to create a web application exactly for
this purpose -- Glitter Gallery [2]. I'm not sure if it's in a usable
state, though.

So... GitHub for now?

[1] https://github.com/gnome-design-team/
[2] https://github.com/glittergallery/GlitterGallery


>
> On Tue, Jul 8, 2014 at 11:32 PM, Mirek M. <mazelm@gmail.com> wrote:
>
>> Hi Stuart, Pedro,
>>
>> 2014-07-08 14:18 GMT+02:00 V Stuart Foote <VStuart.Foote@utsa.edu>:
>>
>> Mirek, *,
>>>
>>> Regards para 1): why would there need to be a developer already in
>>> agreement
>>> to start the process? It would be nice if one, or more, were already on
>>> board, but much of the argument for implementation actually comes from
>>> fleshing out the details of what the enhancement should be.
>>>
>>> Admittedly a developer's understanding of the structure of the program
>>> and
>>> cross platform implementation early in the process improves feasibility
>>> of
>>> implementation and can provide reasonable bounds to the design. But,
>>> waiting for developers to appear and take an interest otherwise stifles
>>> design.
>>>
>>> On the other hand, if there is a reasonable flow of good designs from the
>>> Design process that result in implementation then that flow becomes the
>>> norm. More developers will "check-in" to see what needs to be worked on,
>>> and I'd expect that a fair number would actually make design
>>> contributions.
>>> As is now many do their own design work while implementing their code.
>>>
>>
>> That was my original thought too.
>> However, working without a dev hasn't worked out for us at all.
>> Let me give some examples:
>> * The design of the template dialog was dramatically different from the
>> proposed design because of a lack of designer/developer communication (and
>> I'm mostly to fault there). Things like drag-and-drop to create a folder,
>> design for a single-level hierarchy, a stack switcher-like widget,
>> single-click-based design, etc. were scrapped mostly because of technical
>> reasons and that resulted in design problems and a sub-par experience.
>> * There have been several attempts to design the color picker, but they
>> haven't been brought to a conclusion. The struggle there was that there was
>> no way of telling how it would be implemented -- would the current picker
>> evolve through a series of easy hacks? would it be written from scratch?
>> would LibreOffice support themes by the time it was worked on?
>> * The original Android Remote's coverflow-like slide view moved too
>> quickly. If the dev and the designer worked hand-in-hand, the physics of
>> the switching slides would be adjusted to a more comfortable speed.
>>
>> 2014-07-08 15:45 GMT+02:00 Pedro Rosmaninho <mota.prego@gmail.com>:
>>
>>> Agree with Stuart, waiting for devs to start the process would severely
>>> limit the work. Why not have the designers brainstorm and come up with
>>> creative solutions even if no dev is present at the beginning.
>>>
>>
>> There's no restriction on brainstorming for designers, but whiteboards
>> aren't a place for those. Designers can post their ideas on their user
>> pages or on networks like DeviantArt.
>>
>> Whiteboards should be designed with implementation in mind, and that
>> requires dev cooperation.
>>
>> It would allow for more creativity and cooperation between designers and
>>> even if something fails to atract dev interest it will still result in
>>> the
>>> designers better knowing each other, cooperating and in the fostering of
>>> a
>>> creative atmosphere.
>>>
>>
>> There are a number of things that designers can work on that would have
>> dev support or that don't require dev support (e.g. working on icon sets,
>> reporting and bringing attention to design bugs, ...).
>>
>> There's still room for mockups and prototypes without dev backing, but
>> that should be left to user pages and DeviantArt.
>>
>
>

--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/design/
All messages sent to this list will be publicly archived and cannot be deleted

Follow-Ups:
[libreoffice-design] Re: Revisiting our project workflowDaniel Hulse <simplecontrast@gmail.com>
References:
[libreoffice-design] Revisiting our project workflow"Mirek M." <mazelm@gmail.com>
[libreoffice-design] Re: Revisiting our project workflowV Stuart Foote <VStuart.Foote@utsa.edu>
Re: [libreoffice-design] Re: Revisiting our project workflowPedro Rosmaninho <mota.prego@gmail.com>
Re: [libreoffice-design] Re: Revisiting our project workflow"Mirek M." <mazelm@gmail.com>
Re: [libreoffice-design] Re: Revisiting our project workflowPedro Rosmaninho <mota.prego@gmail.com>
Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.