unity-design team mailing list archive

[Jo-Erlend Schinstad <joerlend.schinstad@xxxxxxxxx>]

On 09. feb. 2012 18:18, Petko wrote:
> Here, I'll explain - with always visible the launcher takes space (for 
> some people too much) .
> With auto hide :
> 1. There is a blank line on the desktop where the launcher should be 
> (you cant put icons there)

Ok. I personally feel that the desktop is a horrible place to keep icons 
at all. If that's still tempting, then I think other solutions should be 
promoted. For instance, organizing your stuff in folders that you access 
by using bookmarks.

> >being on the desktop usually implies that you'll start some app , so 
> it's most logical to have the launcher open

I don't really agree with that. You can't use the launcher without 
either point the mouse at it, in which case it's shown, or using the 
keyboard in which case you're likely less dependent on it being visible. 
It's good to have it displayed by default so that new users have an 
easier time discovering it, but I'll personally use auto-hide immediately.

> 2. It's handy to have the launcher open as much as possible , which is 
> what exactly the dodge windows did .
As much as possible? It's possible to have it open all the time. But 
isn't it likely that you'll either want to display it all the time or 
keep it hidden?

> Here we're talking about making the optimal solution . Keeping some 
> useful (and as far as I know) stable code in the code base is a good 
> thing (when it's not all of the legacy code , but some portion of it ) 
> . We had 4 behaviours , I think reducing them to two and keeping 3 for 
> advanced use in the code base is an optimal solution. I'm giving so 
> much attention to the subject because it is somewhat universal . 
> Here's a few points to having things this way ,as I wrote them  
> elsewhere:

Yes, stable code is good. The problem is that when you're adding any 
code, the code isn't stable. Adding some code in one place might make 
other code unstable. The more code you have, the bigger the chances of 
that happening is. Then the question becomes what those two and three 
features should be. If that's the limit, then you're saying that other 
features can't be added.

> "Here's the four points to keeping such resources :
>
> -they might appear more usable further down the road

Then it might appear to me that it would be wise to add them when they 
become more usable. Not to keep them around _in case_ that should ever 
happen. Otherwise, you'd have to consider that code every time you added 
or changed something until that theoretical moment in time when it 
should suddenly prove to become much more usable. That's a waste of time.

> -they will be available for advanced customisation and/or experimentation

Sure, that'll be nice. For instance, I sometimes flip my right screen to 
vertical when I read books. Ah, how nice it would be if Unity would 
discover that I'm about to read a book and flip that screens orientation 
for me. Perhaps we could suppliment a calendar so that only if I open a 
book on a Friday afternoon should this happen? And optionally have it 
scan international bookstores to recognize the book I'm about to read. 
If it's a comic book, then I might not want to flip the screen. That 
would be an advanced customization option, wouldn't it? Perhaps that 
might become very usable sometime further down the road. :)

> -they generally don't need maintenance

Those kinds of claims generally needs evidence to back them up. That 
sounds very strange to me. How can that be possible?

> -they don't interfere with "keeping the code clean" . The code base 
> isn't an interface , and having a rich code base , if it's stable ,can 
> only be a plus for a developing component "

You are talking about a text document, right? The source code. More 
features means more text. The longer that text becomes, the more 
difficult it is to keep the story in your mind. When that becomes 
difficult, chances of accidentally introducing bugs increase. Have you 
ever listened to a politician speak? They're masters at making you 
forget the questions you intended to ask. They do so by adding lots of 
nonsense in between. Code is the same way. Nonsense means clutter, which 
means less clean code. I'm not calling dodge nonsense, but unnecessary 
features in general.

Am I missing something?

Jo-Erlend Schinstad