[kde-guidelines] Goal of the HIG

[Andrew Lake]

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> 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
> 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/73dd26da/attachment.html>