[haiku-development] Re: Ctrl+Alt window management functionality
- From: Landon J Fuller <landonf@xxxxxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 25 Jan 2013 18:08:53 -0500
On Jan 25, 2013, at 5:04 PM, Axel Dörfler <axeld@xxxxxxxxxxxxxxxx> wrote:
>
>> The idea is quite novel, do you think that this kind of UI concept
>> sets a good example for how we'd like 3rd party software to behave on
>> Haiku? I guess my main concern is that we shouldn't be too novel in
>> the base system inventing new UI paradigms; instead we should take a
>> conservative approach. Let 3rd parties create novel new UI concepts,
>> in the base system we should stick to the fundamentals.
>
> I can't really agree here. I think the complete system (including 3rd party
> applications) should follow a single UI concept (and look).
> I hate applications that stand out, and think they have to invent their own
> concepts for no particular reasons.
I think there's a balancing act; once you commit to something in the base
system it's much much harder to take it back. It's not always clear what will
work, and what won't, and what works often involves evolution over time; this
is easier to do in apps and third-party extensions. Striking the right balance
means that you can let third-party tools explore the design in ways that
introduce much less risk, while not having them diverge too much from
consistent platform conventions that you are certain of maintaining.
There are some notable examples of this symbiosis occurring in
commercially-designed operating systems, whereby an interaction model is
explored, iterated on, improved, and then widely adopted as a third-party
solution, and then is eventually imported into the base system in a way that
meets the often longer-term-focused requirements of an OS. At the same time, I
agree that it is generally better to build a consistent and well-considered set
of standard interaction models and UI.
In this particular case, I'm concerned about too much experimentation in the
base OS. One of the major advantages of cribbing design from BeOS is the amount
of time and effort they already invested that can be directly leveraged --
diverging from that without investing equivalent effort is unlikely to produce
results that are on par with what they've done.
For what my experience is worth, my company produces end-user mobile and
desktop applications, and I'd say the time costs are split almost 50/50 between
time designers spend getting the design right, and the time developers spend on
implementation. I don't believe that's far out of the norm for modern consumer
applications -- it's only in the OSS field that I see developers thinking they
can hash out design solutions in a few hours via e-mail on a mailing list,
instead of in an amount of time that's roughly equivalent to what you'd spend
architecting a large subsystem of a code base.
Which isn't to say I weigh in strongly on either side of this particular issue,
except insofar as I think experimentation by third-parties is a lot safer than
significant divergences to the core design that Be already invested in, and I'd
love to see a design team founded that focused on such things. If I knew how to
recruit designers to work on Haiku I would, but genuinely good UX designers are
hard to recruit even when you're paying them. On top of that, designers need to
be able to have the things they spend considerable amounts of time reasoning
through implemented, but most OSS projects tend to have a bottom-up hierarchy
that somehow puts kernel engineers in charge of user-experience design -- and I
say that as someone who much prefers to spend time in non-user-facing system
code.
I think it'd be great to have a UX-focused design working group, with the first
order of business being the cleaning up and fleshing out of the HIG[1], and
giving them some latitude to define the UX/UI guidelines that exist(ed) from
BeOS, and the task of spending the requisite time to figure out these sorts of
problems. A design organization is almost a mirror of a development
organization when it comes to questions of capability, seniority, and the time
spent architecting solutions to UX problems, rather than code problems. It
seems like there are interested individuals, myself included, and having a more
formal process (wireframes! full color mockups!) could help guide design
decisions in a way that provide for more oversight and input.
Of course, this might all be a terrible idea, but it's just been on my mind a
lot lately -- Haiku is pretty rare as an OSS project for having a decent UI. I
can't say I've seen a successful OSS design organization, and in commercial
settings, it only works when management hires solid designers to go with solid
developers, and they give the designers the authority necessary to dictate
design according to the given product and technical goals.
-landonf
TL;DR; Maybe we could have a working group for design that has some authority
in a way that parallels the development hierarchy, coupled with the
responsibility of spending the time fleshing out designs (wireframes, color
mockups) before they can be implemented. The first task(s) would be in
documenting what design constraints already exist by way of BeOS, and
improvising the HIG as necessary. Insofar as keeping the momentum towards an R1
release is concerned, divergences from BeOS R5 could be avoided in the meantime.
Or it's all a bad idea and I should feel bad, which is OK, too :)
[1] http://api.haiku-os.org/HIG/
Other related posts:
