Few thoughts about Google Summer of Code
One such difficult problem would be to make a visually compelling UI
framework, fully capable of supporting and deploying real production
applications.
On 10/29/2010 1:35 AM, Julian Fitzell wrote:
On Fri, Oct 29, 2010 at 8:47 AM, Andres Valloudavalloud@cincom.com wrote:
Its not just appearance Andres, it's the complete User eXperience:
intuitiveness, ease of use, productivity, fun factor as well as the look
and
feel. A lot of progress has already been made in this area, but there is
still a long way to go because most Smalltalk IDE's have not evolved that
much since the 70's ... that's probably part of why Smalltalk is being
treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we will
make the most progress in this area by concentrating our efforts on the
difficult problems. It makes me happy to see people concerned with how to
make an image from scratch, for example.
As someone who spends much of my time dealing with Smalltalk users,
customers, and prospects, I can say that it does matter to most
people. Solving difficult problems is a very valuable thing to do, but
without doing it in an environment that is broadly appealing
(visually, UX, etc. as Geert says) Smalltalk will never have any
chance of being more than a tiny niche (think of WinAmp or VLC -
neither would have been successful without attractive, intuitive user
interfaces, even though the real reason I used/use them was for the
really practical features).
Julian
On 29. 10. 2010 10:35, Julian Fitzell wrote:
On 29. 10. 2010 09:34, Geert Claes wrote:
Its not just appearance Andres, it's the complete User eXperience:
intuitiveness, ease of use, productivity, fun factor as well as the look
and
feel. A lot of progress has already been made in this area, but there is
still a long way to go because most Smalltalk IDE's have not evolved that
much since the 70's ... that's probably part of why Smalltalk is being
treated like a black and white movie :)
As someone who spends much of my time dealing with Smalltalk users,
customers, and prospects, I can say that it does matter to most
people. Solving difficult problems is a very valuable thing to do, but
without doing it in an environment that is broadly appealing
(visually, UX, etc. as Geert says) Smalltalk will never have any
chance of being more than a tiny niche
Agree completely. Aesthetics is very important moment here, specially in
a world where perception is more important than reality, as Graham very
nicely shown with his examples.
That's why we need to be balanced here, we need to make a better
"perception" (look&feel, marketing, documentation,...) but be careful
not to forget to our "reality" (technical brilliance), which is actually
our stronger point and which is the cause why Smalltalk is resurrecting
again and again
Best regards
Janko
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
Valloud, Andres wrote:
One such difficult problem would be to make a visually compelling UI
framework, fully capable of supporting and deploying real production
applications.
This becomes much less of an issue since most development - I know not all:)
- is moving to the web.
--
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3018731.html
Sent from the ESUG mailing list archive at Nabble.com.
Agreed. UI frameworks are an officially certified Hard Problem. :)
Julian
On 10/29/10, Andres Valloud avalloud@cincom.com wrote:
One such difficult problem would be to make a visually compelling UI
framework, fully capable of supporting and deploying real production
applications.
On 10/29/2010 1:35 AM, Julian Fitzell wrote:
On Fri, Oct 29, 2010 at 8:47 AM, Andres Valloudavalloud@cincom.com
wrote:
Its not just appearance Andres, it's the complete User eXperience:
intuitiveness, ease of use, productivity, fun factor as well as the look
and
feel. A lot of progress has already been made in this area, but there
is
still a long way to go because most Smalltalk IDE's have not evolved
that
much since the 70's ... that's probably part of why Smalltalk is being
treated like a black and white movie :)
But see, I'm already sold, so I just don't see the point :)... IMO, we
will
make the most progress in this area by concentrating our efforts on the
difficult problems. It makes me happy to see people concerned with how
to
make an image from scratch, for example.
As someone who spends much of my time dealing with Smalltalk users,
customers, and prospects, I can say that it does matter to most
people. Solving difficult problems is a very valuable thing to do, but
without doing it in an environment that is broadly appealing
(visually, UX, etc. as Geert says) Smalltalk will never have any
chance of being more than a tiny niche (think of WinAmp or VLC -
neither would have been successful without attractive, intuitive user
interfaces, even though the real reason I used/use them was for the
really practical features).
Julian
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Thanks for this expressions. I fully agree too !!!
We are developing a Business-Process-Management-Suite, called
/OfficeTalk/. /OfficeTalk /has won in the past a few awards. One of the
highest priority is the GUI and the usability.
/OfficeTalk /is made open to systems made with all other technologies
(COM, ActiveX, DotNET, Web, aso). If we propagate more of the existing
systems, Smalltalk gets more acceptance too !
Josef Springer
(JOOPS Informationstechnik GmbH)
Noury Bouraqadi wrote:
Thanks Dennis for this detailed feedback. It's important to keep the community informed.
On 29 oct. 2010, at 05:41, Dennis Schetinin wrote:
We should be more open. We should find a way to start some cooperative projects with other societies/languages.
[...]
In general, it looks like making Smalltalk more open should be our priority, and this is one of the few ways to enhance prestige of Smalltalk among developers.
I fully agree. There are multiple directions to go.
-Applications : We should develop cool applications that target domains that interest users (e.g. mobile applications, web). The look and feel/ user experience is important to have some impact. A recent really cool example is the Event Planning System developed by the belgian company Inceptive. We need to advertise more such applications to the outside of the community. The on-line videos and slides, blogs and the awards are made for this. Still we need more advertisements in places where we can
-GUI : This is coupled with the previous item. We need native widgets. Smalltalk developers should be able to applications that comply with the appearance of other applications. Projects such as MARS (Smalltalk software with Mac OS X widgets) is an example.
-Programming environments : I love the Smalltalk IDE. Still, many developers don't want to change their programming habit. May be not from the beginning. We should be able to develop Smalltalk in an text editor. This was done in GNU Smalltalk and there is also the CORAL initiative. The effort need to be continued.
-Standard/Mainstream protocols, libraries, and infrastructures. We need to provide a bridge to all important pieces of software (e.g. OpenGL). Web frameworks such as Seaside, Aida are definitely a great step in this direction.
-Documentation : Both on-line and paper articles and books. Code examples are important. People new to Smalltalk should quickly find some code to copy/paste and test.
To sum up, there are already different actions. Still, we need to do more. If you have ideas share them with us. Spending a little of your time in one of these actions would be beneficial to everyone.
Noury
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
On Fri, Oct 29, 2010 at 10:17 AM, Graham McLeod mcleod@iafrica.com wrote:
Hi Dennis, Geert, Adres, Serge and other commenters..
Doing good UI's is still quite hard and labour intensive - Seaside provides
a great framework, but we are still working pretty much at the level of HTML
/ CSS concepts. I would like to see a layer describing logical data
structures e.g. List, Tree, Matrix, Document (sequenced set of objects),
Model (spatially arranged and possibly connected objects) and a visual
editor (or very high level DSL) that allows composition of these into user
interfaces with a publish / subscribe event model and choice of suitable
controls and widgets based upon the logical data type. (this one is probably
a bit too big for a GSOC but may be tackled in pieces. )
Squeak uses ToolBuilder to describe UI elements - lists, buttons, code
panes, menus, and the like. Has anyone considered writing a
SeasideToolBuilder to generate HTML/CSS?
frank
Hope some of this makes sense.
Welcome feedback and comments.
Best regards,
Graham
Dennis Schetinin wrote:
… and observations …and questions … mostly inspired by GSoC Mentor Summit
Mentor Summit was a great event! I didn't expect it to be THIS :) Very
pleasant …and very hard for me: so many people, language and culture shock
:) Great experience for me personally. Thank ESUG for choosing and sending
me there.
Bad news: Smalltalk is not popular. Well, it's not that new actually, we
know it. But I didn't manage to fix it :) Seriously: actually, it looks like
everybody knows Smalltalk (they know it existed I mean; few knows it still
exists), but it is treated like a black and white movie. People say "wow!
it's cool" and go to see Avatar. :( So developers don't take Smalltalk
seriously. We (Smalltalkers) know it's a mistake. But we have to show that
for others. And I found myself unable to do that there. I found language
and, more likely, culture barrier is too big to overcome. I didn't manage to
set up a two-way communication with others. So I listened mostly.
And I've heard many interesting ideas… apparently, organizational ideas
mostly. I need some time to process them. So, for now I'll just outline some
directions…
Did we summarize our GSoC results? I thought I've missed them, but
apparently we didn't do it. At least I found only this page
http://code.google.com/p/google-summer-of-code-2010-esug/downloads/list. I
didn't care much before, but now I think it is very important to look closer
at the projects we did within GSoC, understand where we succeeded; where we
failed; did we benefit and could we get more; make some plans for the
future... etc.
I think we should pay more attention to GSoC. It is very important for our
small society. Of course, we can't be sure smalltalkers will be invited
again next year. (One of the things I tried to understand at summit but
still I don't: how does Google select mentor organizations?) But this work
will be very helpful, useful, advantageous… what ever.
We should be more serious about monitoring and controlling our projects.
Since money are involved here, we have a right to. That's money from Google,
but still. I think it should be a bit different from the way free projects
are evolved within Smalltalk society. Since we have such opportunity we have
to benefit as much as we can.
Smalltalk gives me competitive advantages. For that matter I don't want to
:) but now I understand even better: we have to promote Smalltalk. I know
everybody knows that, but I still want to state it once again. And promoting
is not only about advertising and praising. We should be more open. We
should find a way to start some cooperative projects with other
societies/languages. I don't know how to do it. And it's extremely hard for
me as I believe in Smalltalk superiority :) But still we have if we don't
want Smalltalk to die. In general, it looks like making Smalltalk more open
should be our priority, and this is one of the few ways to enhance prestige
of Smalltalk among developers.
--
Dennis Schetinin
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
I'm not sure that's the case. I used that line a lot when I was the Smalltalk Evangelist at Cincom, and it's true - up to a point. However, the prospective developer who looks at the tools from a personal use standpoint cares. So
-- the not quite "standard" widgets in VisualWorks make him think
-- the "all in one windows" thing in Pharo and Squeak make him think
I don't think those are complete showstoppers, but they are hurdles - and they are additional hurdles the Smalltalk community doesn't need. Consider that we already present two big hurdles that we require people to get past:
-- The prospective user can't use his favorite editor
-- The prospective user can't use his favorite source code control tools
the UI hurdle is something that could be dealt with (and yes, I recognize the difficulties). The last two are just there. Given that, the additional UI level one should be considered more seriously
On Oct 29, 2010, at 5:05 AM, Geert Claes wrote:
Valloud, Andres wrote:
One such difficult problem would be to make a visually compelling UI
framework, fully capable of supporting and deploying real production
applications.
This becomes much less of an issue since most development - I know not all:)
- is moving to the web.
--
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3018731.html
Sent from the ESUG mailing list archive at Nabble.com.
Esug-list mailing list
Esug-list@lists.esug.org
http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org
James Robertson
http://www.jarober.com
jarober@gmail.com
On Fri, Oct 29, 2010 at 5:14 PM, James Robertson jarober@gmail.com wrote:
I'm not sure that's the case. I used that line a lot when I was the Smalltalk Evangelist at Cincom, and it's true - up to a point. However, the prospective developer who looks at the tools from a personal use standpoint cares. So
-- the not quite "standard" widgets in VisualWorks make him think
-- the "all in one windows" thing in Pharo and Squeak make him think
But comparing to Ruby, there is no standard UI in Ruby and this not
really annoying for the people, because they deploy their application
on the web.
Regards,
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
The Ruby <developer> sees a text editor - the one he picked. The Smalltalk developer sees the Smalltalk browser (etc). My point is that the UI is the first thing the new Smalltalker sees, and it creates an impression.
On Oct 29, 2010, at 6:19 AM, Serge Stinckwich wrote:
On Fri, Oct 29, 2010 at 5:14 PM, James Robertson jarober@gmail.com wrote:
I'm not sure that's the case. I used that line a lot when I was the Smalltalk Evangelist at Cincom, and it's true - up to a point. However, the prospective developer who looks at the tools from a personal use standpoint cares. So
-- the not quite "standard" widgets in VisualWorks make him think
-- the "all in one windows" thing in Pharo and Squeak make him think
But comparing to Ruby, there is no standard UI in Ruby and this not
really annoying for the people, because they deploy their application
on the web.
Regards,
--
Serge Stinckwich
UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam
Every DSL ends up being Smalltalk
http://doesnotunderstand.org/
James Robertson
http://www.jarober.com
jarober@gmail.com
Serge Stinckwich wrote:
But comparing to Ruby, there is no standard UI in Ruby and this not really
annoying for the people, because they deploy their application on the web.
Hence my remark that standard UI is less of an issue on the web :)
James Robertson wrote:
... Consider that we already present two big hurdles that we require
people to get past:
- The prospective user can't use his favorite editor
- The prospective user can't use his favorite source code control tools
What is the developer's favorite editor/IDE and why? As mentioned before,
this is all about the User eXperience. The developer probably doesn't care
what source code control system is being used, as long as it does the job
and is easy to use.
--
View this message in context: http://forum.world.st/Few-thoughts-about-Google-Summer-of-Code-tp3018404p3018841.html
Sent from the ESUG mailing list archive at Nabble.com.