← Back to team overview

unity-design team mailing list archive

Re: Applications in unity

 

On Mon, Nov 14, 2011 at 23:35, balint777@xxxxxxxxx <balint777@xxxxxxxxx>wrote:

>
>
> frederik.nnaji@xxxxxxxxx 2011. november 14., hétfő napon a következőt
> írta:
>
> On Mon, Nov 14, 2011 at 21:45, balint777@xxxxxxxxx <balint777@xxxxxxxxx>wrote:
>>
>>> Dear Ayatana team,
>>>
>>> Don't get me wrong, but in the current version of Ubuntu it is not
>>> clear, what applications are.
>>>
>>
>> excellent point.
>>
>>
>>> We should define what exactly an application from the User's point of
>>> view is and stay as close as possible to that metaphor. I think, as a user
>>> may expect: an application is a program wich is by no means part of the
>>> system.
>>>
>>
>> An application is a way of employing a device, kind of like a "purpose"
>> or a "use".
>> A thing is considered useful if it has a purpose aka an application, or
>> even multiple purposes, uses, applications.
>> An application is not an icon representing window built on a graphical
>> toolkit showing buttons and toolbars.
>>
>> An application of my laptop is for example messaging, another would be
>> office work, another would be entertainment, and so on and so forth.
>> Today, the misconception about applications is obvious: we are mislead by
>> e.g. Apple's misusage of the word "App" as a marketing strategy.
>> By selling applications as single items in the store, Apple actually
>> seperates functionality from the core system.
>>
>> Imitating this behaviour will only make things worse, so thanks for
>> bringing the topic up, Balint!
>>
>>
>>>
>>> - An application is not used for system configuration.
>>>
>>
>> exactly, that would be a very special case of "application", if at all.
>> configuration would rather be "device maintenance".
>>
>> - An application can be removed from the system without any problems (no
>>> dependency on it)
>>>
>>
>> that's like removing the radio from a car.
>>
>
> Well, if I wanted a CD player instead, then why couldnt i remove the radio
> without causing harm in the car?
>

no, of course you can replace it, sure, there's nothing wrong with removing
the cd player from a car. i was merely complementing your statement with an
example.


>
>
>> - An application is represented by an icon. (This is really important.
>>> For a developer a program may be an executable, or a package, but a user
>>> may think the icon he/she sees IS the applicaion - When I was 6, i thought
>>> that deleting the game's icon deletes the game. I'm sure i'm not alone with
>>> this.)
>>>
>>
>> That's for branded stuff. We live in a world of brands, which
>> unfortunately reminds me of branding in slavery times. I think a true
>> application doesn't need a marketing-style icon, it needs a symbolic icon
>> that carries a semantic value, rather than a marketing one. Symbolic icons
>> for meaningful applications.
>> As you scale up, color and shading can be added, but the symbol itself
>> should already "deliver" when monochrome.
>>
>>
>
> I don't really get your point here. Every icon carries semantic value, and
> that "branding" thing makes people easy to identify the program.
>

branding makes it easier to identify the product. the program is best
identified by a message, and a clear message is best delivered through a
semantically powerful and unabiguous means, such as a symbol.


> I'm sure you wolud be quite upset if you opened banshee instead of
> rhythmbox, because their icon didn't show anything related to their
> brand/identity apart from being a music player.
>

agreed.


> Anyway you're right that the system defaults should have very semantic
> icons.
>

that was all i was trying to say. thanks for putting it straight.


>
>
>> - Applications are icons, he/she can find in the software center and drag
>>> to his/her machine (launcher or dash) to get it.
>>>
>>
>> ok.
>>
>>
>>> I would like to have a desktop, where applications show up with
>>> installation animation, when i buy/download them form the store (like the
>>> iPhone approach). Where an application gets deleted when I drag it to the
>>> trash can. Where progressbars, counters and stikers do not only show the
>>> applications status in the launcher, but everywhere the application appears
>>> (at least in the dash as well).
>>>
>>
>> thank you. An object should indicate its status wherever it is
>> represented. Representing an object with its status indicated in one place
>> and without indicating its status in another place is confusing and
>> inconsistent, it makes the operation of a machine more difficult to learn.
>>
>
> Imagine that you have an e-mail application, which is by some reason not
> pinned to the launcher. Wouldn't it be nice, when you open up dash it
> indicated with a small counter that you have eg. 3 new messages avaiable? I
> can imagine the same behaviour with update-manager, or transmission
> (indicating there are unfinished downloads).
>

superb idea!


> I did not say the current design is inconsistent.
>

you didn't say it's inconsistent, but i say so. Unity is inconsistent
within itself.
that's because its functionality is based upon a mixture of toolsets:
lightdm, gtk, Ayatana, compiz.
if Unity were solely Ayatana, i'm sure it would be consistent within itself.
Window Picker and Workspaces have inconsistent handling of window previews,
for example. Scale addons don't work on Desktop Wall.
Stuff like that only makes everything more complicated, less intuitive,
less fun.
I think it is important to say, when something is inconsistent, because
consistency is an easy rule to remember.

 Actually I think the launcher api is getting great, and could be extended
> on the dash.


+1


>
>>
>>
>>> Where i can find every setting, utility, and system control by typing
>>> into the search box, but not when browsing for applications.
>>>
>>
>> Settings are settings, controls, not applications. Again, language gives
>> us clear guidelines as to how words need to be interpreted.
>>
>
> They are currently listed under applications... ("Find files" is rather a
> utility. You can call it an application though, but "Shut down" has really
> no place there.)
>

+1


>
>
>>
>>
>>> There are a bit wilder ideas about applications which i would like to
>>> discuss also.
>>> - When an application is pinned to the launcher, it should disappear
>>> form the dash. (It makes the application metaphor more clear, with only one
>>> instance of its icon)
>>>
>>
>> I don't know. i'd rather abandon the Launcher entirely on the long run
>> and do everything Unity in the Dash.
>> I think the launcher is good as a transitional solution, shiny icon bars
>> on the desktop are common in Windoze and OSX, plus they look fancy.
>>
>> - The old Windows 95-style approact of icon is bad. The desktop is no
>>> place for an application, but for documents and files. ".desktop" files
>>> shoud not be allowed in the filesystem elsewhere than
>>> /usr/share/applications .
>>>
>>
>> I think the "desktop" metaphor, as ancient as it is, is retarded,
>> computer UIs need a major overhaul, if they still build on that metaphor.
>> We're working with a screen nowadays, it can be layered, it can simulate
>> spacial depth, therein exploiting better the nature of the human visual
>> cortex: we see, think and imagine in 3d, not in 2d. In my opinion, it would
>> be better to consider a screen a screen, a frame a frame and a pointer a
>> pointer.
>> The law of correspondence is one that should be respected, if we want to
>> avoid clutter and noise in our user interface.
>>
>>
>>> I hope you find some of them useul. Best regards:
>>> Bálint Csonka
>>>
>>
>> thanks a lot for an excellent set of ideas! Very inspiring ;)
>>
>
> Anyway, thank you for taking the time to reply, Frederik :)
>

same same ;)

Follow ups

References