looks evolution

> On 4/22/2010 8:21 AM, Ian Trudel wrote:
>>
>> Hi all,
>>
>> I am all about improving the visual appearance of Squeak. I would
>> perhaps consider prioritizing a consistent and coherent user interface
>> instead. There are still some needs in this area.
>>
>> An idea of mine may spark some interest, as far as look-and-feel is
>> concerned. Our community could contact DeviantArt and ask if they
>> would be helping us to get contributions for a complete UI from their
>> community. It could be a simple text "Squeak needs your help!" on
>> their main page and we could set up a page with our requirements.
>
> I like the idea. Does anyone have connections into that community? A
> cold-call probably won't get you very far but if someone who is established
> in this (or a similar) community would pose the idea it might get more
> responses. I would definitely support it.
>
> Cheers,
>  - Andreas

> Hi Ian
>
> Thank you for keeping on pressing on this issue.
>
> On 4/24/10, Ian Trudel <[hidden email]> wrote:
>> Nobody is interested to collaborate? I'd hate to see a good idea die
>> alone in the dark.
> It will not.
>
> I think people _are_ interested in working on this.
> The challenge is to put mechanisms in place which makes it easy for
> people to contribute.
>
> More see below.
>
> It would be great to know what kind of graphic
>> resources is needed to have a fully functional UI and I'd expect
>> Squeak UI guru(s) to give us some feedback. An estimation in numbers
>> of number of images required would be a plus.
>
> Yes, we need to know where the graphic resources (images, icons, color
> definitions, border with definition etc) are located. Currently I have
> no idea where to look for this.
>
>
>> A requirement sheet could further include:
>>
>>    * A comprehensive list of our most important points in term of
>> visual style (and usability?)
>>    * A comprehensive list of graphic resources required (icons, menu
>> and window decorations, buttons, splash screen, etc)
>>    * Visual effects and transitions, if any
>>    * Files and images formats, if any specific ones are required
>>    * Accepted License(s) for contributions
>
> YES, the license is important.
>
>
> And we could have different loadable libraries with graphics.
>
> Currently we deal mainly with bitmap graphics. But the source file
> should be vector graphics wherever possible
>
> http://en.wikipedia.org/wiki/Open_Clip_Art_Library
> http://planet.openclipart.org/
>
> There is the Tango Icon library we could put to immediate use to
> replace the 'cartoon' arrows.
> **)
> The have as well started a table giving a list of visual metaphors
> http://tango.freedesktop.org/Icon_Metaphors
>
>> We could also stipulate our preferred visual style(s) but it should
>> remain open.
> Yes
>> We should focus on the most important elements (e.g.
>> related to usability, such as colours that can be looked at for hours
>> and hours without bursting any people's eyes).
>
> Yes, a list of priorities is an immediate need. However as this is
> open-source development this list is just a list of suggestions and
> people may pick to work on something what they feel comfortable with
> or what they have fun with.
>
> So far we have a solution for changing the background (a few hours
> old, see another thread).
> As the next item I would see the replacement of the navigation arrows and
> then
> the implementation of a chooser for color themes (I think there are
> mechanisms in place - we just have to make use of them - i.e. polish
> and enhance them)
>
>
>>Graphic designers need
>> to be inspired and have some freedom for their creativity, especially
>> when it comes to contribution given with their heart. :)
>
> Yes.
>
>> I believe Polymorph is currently not loadable in 4.1 and our UI is not
>> really skinable. We should put in place a small plan to make it easy
>> for graphic designers to test their graphics in Squeak, if possible.
>
> This is linked to your remark above where you say that we need a list
> of graphical elements (including a description how they are supposed
> to be named) to make it easy for non-programmers to come up with
> another set.
> I.e. something like
>
> myGreatTheme-backarrow.png   (this name consists of the theme name
> together with the resource name - just a start not something really
> worked out)
>
>> This will increase the number of contributions.
>
> Indeed. See the 'personas' movement of Firefox 3.6. You may choose
> among 10 thousands of 'personas'.
>
>> A simple one page requirements sheet would be more than enough.
>
> For the start yes, but I bet you'll see that it will develop quickly .....
>
>> Anything else should be on?
>
> I think some more research has to be done to find out and document in
> a summary view what is already in the system.
> I think there are graphic themes. Let's give it a try and do some more
> to find out what is lacking with the current schemes.
>
> I we should work on a list of action points
>
> - background chooser (done by Steve Wessels)
> - inventory of graphics
> - dig out things from the past and summarize what is useful for the
> future (entry point for example http://wiki.squeak.org/squeak/1114,
> Appearance / Themes / Skins - October 2006)
> - evaluation of current situation - what does the 'theme' mechanism in
> the preferences browser deliver? (see screenshot)
> - naming scheme for graphical elements of the user interface
> - polishing the preferences browser
> - loader for UI-elements ('personas' idea from Firefox; maybe it is
> possible to tap into that - i.e. just use the 'personas')
> - list of further actions
> - .......
>
> Hannes
>
>
> **) I do not dislike the cartoon icons as such but for a more general
> audience I think we should have something more neutral.  The
> 'industrial', slightly 'retro' look we now have is quite OK for the
> time being I think. In the end we should have  different well worked
> out skins and themes people can choose from. One reason for this is
> that people may adapt Squeak for their specific application needs. Or
> a game programmer might want to have something particular.
>
>
>
> P.S. I am 'out of Squeak office' for the next 3 hours.....
>

> There are several reasons I have not continued to keep the Skins project up
> to date:
>  1.  I actually like the existing look and feel.
>  2.  It surprises me there is core demand for this capability.  I have
> always thought of it as a "goodie" and more of a personal fun indulgance.  I
> may be wrong about this impression, of course.
>  3.  Bringing the Skins project up to date usually took about a weekend to
> do because the base Squeak design kept changing so much.  So the project
> would drift away with other personal Squeak projects taking priority -
> including a Laser Game tutorial rewrite I keep promising to complete.
>
> Mostly, I haven't kept Skins current because I like the existing look.  :)

> Hi Hannes and Steve,
>
> Thanks for your feedback guys. I particularly appreciate your input,
> Hannes. By the way, Steve, I am a big fan of your Laser Game tutorial.
> It's great! Have you considered having your tutorial in Squeak
> HelpSystem? :)
>
> I absolutely think we should focus only on a simple one page
> requirements at the moment, based on feedback from our community and
> conversations with Andreas. Let's build a relationship with graphic
> communities. We are likely to spend time on refining our knowledge,
> documentation and UI as time goes by. Realistically, if only we get a
> bunch of icons within the first 6 months, that would be really great.
>
> The facelift Squeak has experienced is good and an improvement over
> what we previously had. The main issue is pertaining to the fact that
> the facelift is bringing Newspeak look-and-feel into Squeak. As far as
> visual identity is concerned: it looks like Newspeak, then it is
> Newspeak. This facelift buys us some time but we're going to lose our
> identity overnight (at least in term of branding).
>
> Your comment about Personas for Firefox is interesting because it
> reminds me that Squeak is the Smalltalk for multimedia. Ironically,
> perhaps, I am not sure graphic designers will be thrilled to use
> Squeak. On the long run, we may have to provide some kind of Smalltalk
> Starter Guide for Graphics. If they manage to use it and like it, then
> we get more users and more graphics.
>
>> Yes, we need to know where the graphic resources (images, icons, color
>> definitions, border with definition etc) are located. Currently I have
>> no idea where to look for this.
>
> Extra > Standard Graphics Library contains some. The resources are
> often encoded into methods but sometimes into dictionaries I think.
> There is a resource manager but I am not sure how it works nor if it
> is used at all. I know where some resources are but nowhere enough to
> make a list. Besides, I have to work on my relationship with Morphic.
> We need gurus to give us feedback.
>
> Would Creative Common an acceptable license? Which other licenses
> would be acceptable? (Board members, what do you think?)
>
>> Yes, a list of priorities is an immediate need.
>
> We should first consider what kind of priority facelifting should have
> among the current priorities Squeak has (e.g. 4.2 roadmap). As I
> wrote, the Newspeak look-and-feel buys us some time. At least time to
> build a relationship with the graphic communities.
>
>> myGreatTheme-backarrow.png   (this name consists of the theme name
>> together with the resource name - just a start not something really
>> worked out)
>
> A small standard guide would be much needed, indeed. Provided that a
> resource manager would handle resources, importing and exporting, that
> could make it much easier.
>
>
>> I think some more research has to be done to find out and document in
>> a summary view what is already in the system.
>
> Documentation is a major task by all means. I would rather favour
> building a relationship with graphic designers. My understanding is
> that beautiful concepts don't get far in our community if they are not
> practical enough.
>
>> I think there are graphic themes. Let's give it a try and do some more
>> to find out what is lacking with the current schemes.
>
> Would you care to elaborate? I would rather hope graphic designers
> tell us about our shortcomings. Some of them are fine UI designers.
>
>> I we should work on a list of action points
>>
>> - background chooser (done by Steve Wessels)
>> - inventory of graphics
>
>> - dig out things from the past and summarize what is useful for the
>> future (entry point for example http://wiki.squeak.org/squeak/1114,
>> Appearance / Themes / Skins - October 2006)
>
> What would be our immediate gain in doing this? I suspect it won't
> give us much. It also remains a documentation task. My point being we
> should not burden ourselves in order to ensure the success of this
> idea. However, we can provide new documentation based on our
> requirements to be integrated. Digging is the work of archaeologists
> and historians. It's long and boring and this won't get many of us
> motivated.
>
>> - evaluation of current situation - what does the 'theme' mechanism in
>> the preferences browser deliver? (see screenshot)
>
>> - naming scheme for graphical elements of the user interface
>
> I like that. Morphic is very confusing at times.
>
>> - polishing the preferences browser
>> - loader for UI-elements ('personas' idea from Firefox; maybe it is
>> possible to tap into that - i.e. just use the 'personas')
>
> By the way, would Toolbuilder be skinnable?
>
>
>> There are several reasons I have not continued to keep the Skins project
>> up
>> to date:
>>  1.  I actually like the existing look and feel.
>>  2.  It surprises me there is core demand for this capability.  I have
>> always thought of it as a "goodie" and more of a personal fun indulgance.
>> I
>> may be wrong about this impression, of course.
>>  3.  Bringing the Skins project up to date usually took about a weekend to
>> do because the base Squeak design kept changing so much.  So the project
>> would drift away with other personal Squeak projects taking priority -
>> including a Laser Game tutorial rewrite I keep promising to complete.
>>
>> Mostly, I haven't kept Skins current because I like the existing look.  :)
>
> Steve, I think it's the reason why Squeak has very slowly evolved
> graphically. Many old timers were used to the look and like it,
> perhaps ignoring a bit its flaws. It took a long time to get the
> facelift we have now. In the spirit of rejuvenating the community with
> new members, the look matters. Besides, in term of deployment,
> skinning is a great feature — otherwise forever stuck to write custom
> UI components.
>
> JavaFX is an interesting case study because it understands building
> UIs require different people (programmers, graphic designers, etc).
> Business logic can be implemented in Java. JavaFX has a declarative
> language for its UI, UI builder, and other support for graphic
> designers. It's fairly easy to build good looking apps.
> http://javafx.com/samples/
>
> All the best,
> Ian.
> --
> http://mecenia.blogspot.com/
>
>

> On 25.04.2010, at 06:02, Ian Trudel wrote:
>>
>> Would Creative Common an acceptable license? Which other licenses
>> would be acceptable? (Board members, what do you think?)
>
> Hard to answer, and I wouldn't know whom to ask. SFC maybe? The MIT license makes no restrictions whatsoever. CC means "some rights reserved".
>
> All CC-NC variants are out obviously. CC-ND is impractical, we need to be able to modify stuff. And CC-SA does require sharing - which is not a bad thing in itself, but MIT does not require it.
>
> The only one I could imagine for inclusion in Squeak would be CC-BY, which only requires attribution, but has no further strings attached. But IANAL and every license we add complicates things. It would be better if it was simply given under MIT.
>
> - Bert -
>
>
>
>

> 2010/4/25 Bert Freudenberg <[hidden email]>:
>> On 25.04.2010, at 06:02, Ian Trudel wrote:
>>>
>>> Would Creative Common an acceptable license? Which other licenses
>>> would be acceptable? (Board members, what do you think?)
>>
>> Hard to answer, and I wouldn't know whom to ask. SFC maybe? The MIT
>> license makes no restrictions whatsoever. CC means "some rights reserved".
>>
>> All CC-NC variants are out obviously. CC-ND is impractical, we need to be
>> able to modify stuff. And CC-SA does require sharing - which is not a bad
>> thing in itself, but MIT does not require it.
>>
>> The only one I could imagine for inclusion in Squeak would be CC-BY, which
>> only requires attribution, but has no further strings attached. But IANAL
>> and every license we add complicates things. It would be better if it was
>> simply given under MIT.
>>
>> - Bert -
>>
>>
>>
>>
>
>
>
> --
> http://mecenia.blogspot.com/
>
>