Hi Stuart, Pedro, 2014-07-08 14:18 GMT+02:00 V Stuart Foote <vstuart.fo...@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.pr...@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+unsubscr...@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
