[kde-guidelines] Goal of the HIG

[Jens Reuterberg]

Personally I see two stumbling blocks to the HIG

One is easy of access and the other is "selling the need".

By providing simple examples - perhaps even a cliff-notes version 
of all we solve ease of access. Pictures with good and bad 
examples.

Selling the need is trickier. Now unlike Gnome we can't put our foot 
down and say "ok this is is the way we want it" - so we need to sell 
the sizzle instead of the sausage (to quote Terry Pratchett's 
character Cut My Own Throat Dibbler). The sensations and not the 
real object, essentially. We can't deliver a complete set of looks for 
everyone, there simply aren't enough of us so we need to sell the 
urge to make it look like our suggestions. So the seconds we have 
some good HIG's for it we should sit down and do mockups of 
"apps we wish existed" and make certain everyone and their 
grandmothers sees them and talk about them.

Really pick a part what we would love - then get everyone involved, 
from Interaction to visuals to icons. Just go nuts. What would a 
perfect "KDE suite" look like? What would "made for Plasma" be 
like? 

We pump this out to the community by introducing first the plans 
and then inviting everyone to talk and toss ideas of applications 
(that follow the HIG to the letter, thats the restriction). That way we 
gain
1) everyone is talking about it
2) any kinks in the HIG's bit that are unclear or not inspiring enough 
gets ironed out in that process
3) we get brilliant ideas thrown at us

On Sunday 27 July 2014 22.10.39 Philipp Stefan wrote:
> 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