[kde-guidelines] Goal of the HIG
Philipp Stefan
sogatori at gmail.com
Sun Jul 27 20:10:39 UTC 2014
I think I generally agree with you Andrew. Especially the blog posts
seem a good idea to propagate our idea to the masses (of developer :). I
also really like your examples in the mockup toolkit.
I agree that we can't and should not cover every case in the HIGs, they
should encourage to learn design skills.
However, I genuinely think that there are some parts where a stricter
approach is desirable. I'm mainly thinking about Plasma integration like
notifications, status notifiers and system tray plasmoids.
Widgets are my other pit peeve right now. I really do think that we
should make some kind of widget collection when QtQuickWidgets become
more common. By basically only telling developers how it should look and
behave we "force" everyone to reimplement the same ideas in each
application separately. I think kinda think that's a waste of man power
and on the other hand leaves opportunity to accidentally leave something
out. But that's a think for the future.
Heiko said that some of the document are much more a basis for our work
that the finished guidelines. Which is relieving. I'm sorry that this
sounds much more negative that intended.
Another thing that still makes me think is our use of the wiki format.
Almost all HIGs I read use a website with some kind of navigation bar
that that where one can see where one's at and what will come next. Some
topics e.g. Animations are then separated into several pages to make the
whole thing more digestible, so to speak. Maybe we should think about
this as well? Adapting our wiki organisation or adopting some different
site for the ""real"" developer guide (the concept I spoke about
earlier. A guide that take a dev through all the design considerations
step by step)?
But like David has suggested, I think Akademy will be an excellent place
to get feedback from developers and to make plans about how to handle
this in future.
On 27.07.2014 20:06, Andrew Lake wrote:
> Philipp I entirely agree with your concerns.
>
> I'm personally aiming for the following in the visual design portion
> of the HIG:
> - Provide clear but concise guidelines in the HIG.
> - Don't try to document and solve every potential design ambiguity in
> the HIG. Let examples help with that.
> - Provide examples in the mockup toolkit.
> - Provide examples and guides in the form of blog posts. The main
> reason I prefer the blog post approach is that design evolves along
> with problems and their solutions. We need a more timely context for
> things like examples. We also need to actively encourage folks to NOT
> wait for instructions but to just do - try stuff. Design is learned by
> doing, not reading about doing. That's what the VDG forums are for: to
> learn together.
> - Leave room for creativity and innovation. We can't put a straight
> jacket on the inherently creative process of design. It needs
> structure, no doubt, but it shouldn't become just an exam with folks
> nitpicking to tell you exactly how you failed on this or that
> arbitrary point.
> - We can provide theoretical basics and lengthy rationale for any
> guideline in separate sections or pages. That makes it easier to focus
> on more direct, concise, digestible guidelines.
>
> Anyway concise guidelines + examples in blog posts is the best
> approach I think.
>
> I hope to revisit several of the guidelines related to visual design
> and work collaboratively to strip them down to the essentials so that
> designers and developers aren't wading through reams of text. If I'm
> being honest, while Baxley's model is quite excellent for learning
> about modelling a user interface, I'm not entirely certain it will be
> the best long-term vehicle for communicating general design
> guidelines. We're all learning as we go though so I'm sure we'll all
> get better at this over time. :-)
>
> Hope this helps,
> Andrew
>
>
>
> On Sun, Jul 27, 2014 at 5:10 AM, Philipp Stefan <sogatori at gmail.com
> <mailto:sogatori at gmail.com>> wrote:
>
> Hello everyone,
>
> I'm not sure if this is the right place to voice my concern as I
> want to discuss our general approach to to HIGs.
> Important disclaimer: I don't want to criticize anyone here. You
> are all some doing important work and I'm confident that we can
> bring KDE Software forward. Also, this applies not to all HIGs,
> like the layout patterns etc.
>
> I like this proposal, I think it includes everything that needs to
> be said and a bit more. My concern is, however, that we create
> more and more guidelines for the developers to read. I fear that
> we increase the load of the developers instead of easing it. Yes,
> we write guidelines, but we have more and more guidelines for them
> to read. We can, of course, keep the guidelines as short as
> possible, but that won't help us much as long as we create ever
> more of them. Another thing we have to work against is that KDE
> doesn't have long standing history of high quality usability
> design. This kind of quality is also a learned skill, and I think
> we are not there yet.
> Another point why other platform have good designed applications
> is IMHO that they try to take as much weigh off the developers.
> Of course all the HIGs are work in progress and always in a state
> of change, but I think we really should focus more on making
> guides and not just guidelines. I think we should make a guide
> that shows step by step how make a good designed, integrated
> Application. The guide should cover everything from point 1 of
> basic considerations over wording and animations to integrating
> into Plasma in a linear way. Of course we can always reorganize
> the HIGs in a way to fit this ideal or write such a guide, but I
> think we have to keep this concept in mind to come up with
> something that really helps developers.
> The way we currently organize things is a bit overwhelming for me
> personally. There is no way to progress through the Usability HIGs
> without having the page opened and open new tabs. It really
> resembles the Wikipedia style much more than it does resemble a
> guide you'd find in a book (which is what I think we should strive
> for).
>
> Another big thing is that we leave much to the developers which
> then balloons up our guidelines. I think ideally we'd have a e.g.
> pre-made search widget with a predefined behaviour so that we only
> have to tell developers how to feed it with information and where
> in the application to integrate it.
> I think the "putt the button here, the icon there and it should
> behave this way" approach has failed us before. Personally I think
> that design guidelines and design patterns should not be as
> separated as they currently are. Take animations for example (I
> know it isn't finished yet, great work btw! :), I don't think we
> should tell developers how to animate certain widgets. Their
> behaviour should be as pre-defined as possible, so that we only
> have to give them general guidelines, with examples of DOs and DON'Ts.
>
>
> I'm sorry if this doesn't sound too coherent, but I have problems
> thinking clearly right now. Anyway, I hope you get what I mean. I
> don't think what we're doing is wrong, but I think it could be
> improved when we would approach our work a bit differently.
> Naturally this won't happen in this or next cycle. To say it
> cynically, throwing a bunch of text at people won't change much.
>
> Phil
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org <mailto:kde-guidelines at kde.org>
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>
>
>
>
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140727/ef28e3dd/attachment-0001.html>
More information about the kde-guidelines
mailing list