
Hive's Design Principles - lukey1909
https://blog.hive.com/hives-7-design-principles-c59d593ae58b#.33d6mc9n6
======
SCdF
> Options are a cop out. It’s the designer’s job to figure out the best way to
> use the product, and delegating that choice to the user is pure laziness.
> Hive only resorts to options as a last resort.

I think if you are building a simple tool to solve a simple problem, this
makes sense.

On the other hand, I think this gets abused in the _other_ direction: by
designers using this as an excuse to not think about flexibility, or engage in
humility. It's like the misuse of premature optimsation, but for designers.

For example, I think it's instructive that almost[1] none of the popular pro
tools in any industry follow this guideline. Those tools are not for easing
users in, they are for getting shit done: they understand that the idea that
some UX designer can come along and tell the entire photography world how to
process raw files, or tell developers how to build software in N different
languages, or what a film editor's process should be for making movies etc, is
utter druff.

This is why, as I understand it, the film industry reacted to strongly and
negatively to Final Cut X: Apple were saying "we don't care what your current
process is, you must now edit films this way, in this order, using this
process, because we know better".

[1] I wanted to just say "none" here, but I obviously haven't used all pro
tools

~~~
svantana
Agree 100%. And even if it's not a pro tool, what's wrong with having options?
I think it comes down to two reasons:

1) It clutters the user experience

2) App designers are benevolent gods that keep users from self-harm

Now 1) I can understand, though in that case I prefer something like Overcast,
where the settings menu has a submenu called "Nitpicky Details", for those of
us who really care. 2) seems to be a prevalent opinion in the business these
days -- while it makes sense for security on mobile devices (no root access
etc), a lot of times it's just pure conceit IMHO.

------
hammock
The principles seem to contradict themselves at least a couple times.

Don't guess what they want to do (Predictable) and leave it Open; yet you know
what they should do and don't give them an option (Opinionated).

And

Don't surprise them (Predictable); yet surprise them (Delight)

~~~
ams6110
Delight, reward ... no. Just help me do what I need to do, and try to stay out
of my way.

------
Animats
_" Options are a cop out. It’s the designer’s job to figure out the best way
to use the product, and delegating that choice to the user is pure laziness."_

Yes. Open source does not get this at all.

~~~
rossy
No. Removing options seems to be a common trend in modern software design and
I hate it. The prevailing wisdom seems to be that if there's a choice between
doing something two different ways, rather than adding an option, the
developer should pick the solution that fits 90% of their target audience and
ignore the remaining 10%. The problem with that is that every time you make
that decision, you ignore a different 10%, and eventually your software is
only suitable for users who stay inside the box that the developers made for
them, not the long tail of users with niche use cases. I think open source
devs don't "get" this because they tend to write software to scratch their own
itches and they often have their own niche use cases. Maybe the reason they
had to scratch their own itch in the first place was because other software
was too inflexible to fit their needs.

Of course, some open source projects do have this philosophy, and when they
start removing options, I switch to something else. GNOME is a good example. I
wish the current version of Nautilus (GNOME Files?) had half the options of
the file managers that forked from earlier versions of Nautilus (Nemo and
Caja,) because I actually use those options.

~~~
teh_klev
> Removing options seems to be a common trend in modern software design

Here's a Slack example of this. We moved from HipChat to Slack and two of the
"options" we as a team dearly miss are:

1\. Being able to set a status that reflects what we're doing if unable to
chat for the time being, not just a binary online or away. Now I have to
inform the team I'm on a conf call or will "brb - making lunch" in a chat room
which distracts everyone. HipChat was pretty flexible that way, it's a small
thing, but for our team hugely important, especially for remote workers.

2\. Being able to specify how long I'm AFK before setting me to "Away".
Sometimes I take calls on my mobile (we have apps for our internal
SIP/asterisk stuff) and I like to wander around when chatting because it
stretches my legs. But I find annoying that on longer calls Slack assumes
after 30 mins of no activity I'm "Away" and "grey blobs" me making it look
like I'm completely offline. Unfortunately the "Snooze notifications" don't
cut it because it still doesn't let me convey, at-a-glance, why I'm deferring
your messages.

From googling around it seems these are common gripes that Slack don't see as
a priority to fix.

Don't get me wrong, there's a lot of things Slack does well, but as paying
customers, not addressing these two issues causes some low level resentment.

------
wai1234
These appear to be incomprehensible drivel.

------
trengrj
Note: this about hive.com not Apache Hive.

------
Dawny33
Wow! I thought it's Apache Hive.

We're officially out of names :(

------
smegel
The title is both inaccurate and misleading.

> Hive’s 7 Design Principles

They are _Hives_ design principals. Not necessarily for everyone.

~~~
sctb
Thanks, we've updated the title from “Design Principles to Make Great
Software”.

