Such a pretty, pretty, pretty, pretty, pretty, girl...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Such a pretty... (+ BUG)

Antony Blakey-4
Andy Bower wrote:

> Antony,
>
>
>>>>I think the private/public + deprecated idea functions well. And of
>>>>course the product is fantastic, but not yet perfect, so...
>>>
>>>FWIW, I find the deprecated icon to be much less obvious; that little
>>
> orange
>
>>>thing was very helpful.
>>
>>My point there was that deprecation can now be orthogonal to
>>public/private. but either I spoke too soon, or there's a bug - the icon
>>shown for public deprecated is the private deprecated icon, which makes
>>me think that the attributes aren't treated orthogonally, merely that
>>the deprecated icon has changed.
>
>
> There is no need for an icon to represent deprecated private methods. By its
> very nature a private method that is deprecated will be removed. The new
> deprecated icon is now meant to suggest that a former public method is now
> private and will be removed in a future version.

I which case the menu should indicate private. But then if I remove
#deprecated., should it go back to public or private?

Currently if I select the public category I see the red icon for
deprecated methods, which in that interface absolutely means 'private'
given that the only difference between the public and private icons is
the color.

In my opinion you are overloading the icon with a meaning i.e. 'suggest
that...' that is confused with the meaning of _being_ public or private.
If you could add deprecation to the icon independently of its
public/private status...

-------------------------
Antony Blakey
mailto:[hidden email]
Linkuistics Pty Ltd
Adelaide, South Australia


Reply | Threaded
Open this post in threaded view
|

Re: Such a pretty, pretty, pretty, pretty, pretty, girl...

Antony Blakey-4
In reply to this post by Andy Bower
Andy,

Before I respond to the technical points - I'm sorry that these postings
frustrate you. To have such an active community that so identifies with
the product and cares about such things is a great thing. I know I can
modify Dolphin to suit my personal preferences, but I've given my
_opinion_ because as a long time developer of shrink-wrapped software
I've been in your position and really benefited from hearing the (even
trivial) opinions and preferences of users. In a previous life I've had
users fly halfway across the country (at their expense) just to sit with
us and give feedback to make the product better. Better in _their_
opinion, sure, and sometimes we felt like the clients lost sight of the
essential fact that it was _our_ product that they chose to buy, and we
sure as hell didn't need more people telling us how to do our jobs and
giving opinions on what the key accelerators should be... but they were
just excited and amazed that they could interact in that manner with the
developers of a product that was so essential to their livelihood.

Anyway, sorry for preaching to the already experienced. I think Dolphin,
and D5 in particular is fantastic. I never want to program in anything
else, every again. Well, maybe a bit of Haskell or Caml. These issues
are merely trivial icing-on-the-cake things, so please don't turn to drink!

Andy Bower wrote:

> Antony,
> I suggest you run up RC1 against Dolphin 4. You will see that the system
> folder sizes are:
>
> 557@348 D4
> 562@356 D5
>
> This means that the new folder with large icons is 5@8 pixels larger. Hardly
> a great loss of screen real estate. If this bugs you then use the system
> options to select #largeIcons rather than #tiledIcons and you can then
> sensibly shrink the window to 455@256 . Go to small icons and you get even
> moe space. Good enough?

I've not really used D4. I bought D4 only after experiencing D5, and
hence I really bought into D5. I switched to largeIcons with 32@32 and
it's fine. I think the initial impression would be better if largeIcons
32@32 was the default.

Overall I think you've done a great job visually. D5 has a high quality
look and feel.

> The ball is part of Dolphin brand (which up until now has been a bit of a
> foreign concept in the Smalltalk world). To us the idea of brand is
> important and therefore the ball is important too. You'll find, though, that
> the ball in the 16x16 icons and toolbar buttons is now one pixel smaller
> than it used to be in D5 or earlier beta, thus saving more space.

The previous company I started did a fair amount of corporate branding
work, especially brand translation for electronic media, so I understand
your desire for a strong brand.

I think your branding intention is correct, as is the fact that your
external icons contain your device. I don't however beleive that the
icons within the application need to contain the device, either in the
larger form (as in the system folder) or in the icons. I think that you
gain perceptual space in the icons particularly by removing the device.
Pervasive branding doesn't depend on repetition of the device within the
application.

A bit more strongly asserted than a opinion, but there you go :)

-------------------------
Antony Blakey
mailto:[hidden email]
Linkuistics Pty Ltd
Adelaide, South Australia


12