<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
I agree that we can't and should not cover every case in the HIGs,
they should encourage to learn design skills. <br>
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. <br>
<br>
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.<br>
<br>
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. <br>
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)? <br>
<br>
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.<br>
<br>
<div class="moz-cite-prefix">On 27.07.2014 20:06, Andrew Lake wrote:<br>
</div>
<blockquote
cite="mid:CAKFiHE8JVN3=0K_yy8U14HKp6HwKKis7z8zo5++B+UhTTa3OAg@mail.gmail.com"
type="cite">
<div dir="ltr">Philipp I entirely agree with your concerns.
<div><br>
</div>
<div>I'm personally aiming for the following in the visual
design portion of the HIG:</div>
<div>- Provide clear but concise guidelines in the HIG.</div>
<div>- Don't try to document and solve every potential design
ambiguity in the HIG. Let examples help with that.</div>
<div>- Provide examples in the mockup toolkit.</div>
<div>- 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.</div>
<div>- 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.</div>
<div>- 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.</div>
<div><br>
</div>
<div>
<div>
Anyway concise guidelines + examples in blog posts is the
best approach I think.</div>
<div><br>
</div>
<div>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. :-)</div>
</div>
<div><br>
</div>
<div>Hope this helps,</div>
<div>Andrew</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Jul 27, 2014 at 5:10 AM,
Philipp Stefan <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sogatori@gmail.com" target="_blank">sogatori@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hello
everyone,<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
Another point why other platform have good designed
applications is IMHO that they try to take as much weigh off
the developers.<br>
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.<br>
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).<br>
<br>
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.<br>
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.<br>
<br>
<br>
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.<br>
<br>
Phil<br>
<br>
_______________________________________________<br>
kde-guidelines mailing list<br>
<a moz-do-not-send="true"
href="mailto:kde-guidelines@kde.org" target="_blank">kde-guidelines@kde.org</a><br>
<a moz-do-not-send="true"
href="https://mail.kde.org/mailman/listinfo/kde-guidelines"
target="_blank">https://mail.kde.org/mailman/listinfo/kde-guidelines</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
kde-guidelines mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-guidelines">https://mail.kde.org/mailman/listinfo/kde-guidelines</a>
</pre>
</blockquote>
<br>
</body>
</html>