Seventy-eight people are subscribed to this mailing list for Lively. Eighteen people are subscribed to the digest. I want to find at least one individual who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this on this mailing list alive daily. No coding involved necessarily and it ought to be fun and rewarding.
I made an effort to get started over at Google Drawings - Google Drawings already supports live collaboration. At some point these drawings could be exported as SVG and imported into Lively worlds. I'm also currently working on a design document to explain some of these drawings and related concepts.
Thanks, Philip Weaver
|
Hi, Phil -
Although I haven't said a word until now, it's only because I was
travelling and am still juggling a bunch of different
responsibilities.
I've been trying to juggle the notions of worlds and menus and
palettes for the many possible modes of use of lively, and I
think that tab-based palette panels are ideal. Integrating this
with browsing is also very cool.
I made a run at common code for windows and tabs at one point,
which should reduce the work to merely making palettes work with
windows, except it appears that code didn't make it through one of the
windows updates. My theory was that tabbed panels are exactly
like windows from the standpoint of the content, and the only real
difference is in the behavior of the two kinds of tabs. If I get
some time, I'll get this part working again.
The other thought I had, which I've voiced here before, is that
we need to make it a primary goal to have Lively be the vehicle of
choice for us to do such mockups and presentations. It was this
commitment that made Squeak into the wonderful media tool that it is.
Furthermore, it's just not that hard. If we just had 3 or 4 of
us working on it for a month I think we could reach a major plateau.
So I guess this could be a companion message to yours -- folks
who want a no-coding project could help you out, and those who want
some simple (*) coding projects could help make Lively into a better
composition environment.
And let's not forget the real challenge:
- to be able to build Phil's vision faster in
LK than to mock it up elsewhere ;-)
(*) truly these are simple tweaks for the most part -- nothing
like getting WebDAV or SVG working. If someone doesn't beat me
to it, I'll post a starting task list in the next few days
Seventy-eight people are subscribed to this mailing list for Lively. Eighteen people are subscribed to the digest. I want to find at least one individual who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this on this mailing list alive daily. No coding involved necessarily and it ought to be fun and rewarding. I made an effort to get started over at Google Drawings - Google Drawings already supports live collaboration. At some point these drawings could be exported as SVG and imported into Lively worlds. I'm also currently working on a design document to explain some of these drawings and related concepts. http://tinyurl.com/lively-panel/ Thanks, Philip Weaver
|
In reply to this post by Philip Weaver
I want to find at least one individual on this mailing list who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this alive daily. Dan, I very much understand how drawing Lively mockups in Google Docs might be interpreted. I used to work at Apple and I understand the concept "not invented here." I also understand the preference to develop Lively and Smalltalk directly within itself. Yesterday evening I watched "The Pixar Story" on television. John Lassiter explained "Artists challenge the programmers. Programmers inspire the artists." This might be a challenge. Mockups I create will develop in Google Drawings until Lively becomes an application for vector illustration. Google Drawings does export to SVG.
Some people look at an empty canvas and see nothing. Others look at Lively and don't understand. I want to help them understand today. I want to find at least one individual (out of 98) on this mailing list who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this alive daily. On Tue, Jun 22, 2010 at 6:20 PM, Dan Ingalls <[hidden email]> wrote:
|
My artistic ability is pretty much nil but I wholeheartedly support this idea. After getting back into Smalltalk after several years of OS X and iPhone programming it's not a stretch to say the user experience leaves something to be desired.
On Tue, Jun 22, 2010 at 7:04 PM, Philip Weaver <[hidden email]> wrote:
|
Hi Steve, thanks for writing.
The goal really is to help others visualize what potential Lively has, help modernize, and to keep conversation going. Dan, Jens, Robert, and HPI are always committing to the repository - but Lively needs some more structure (and perhaps illustration support). I'm aware of every web-based toolkit and, still, nothing else compares. Several other web toolkits are very, very polished but nothing else supports direct manipulation and vectors.
Steve, your background is awesome and you have more artistic ability than you may think. I know that you have good taste. :-) The main thing is please try to find time to keep this conversation going to help generate more interest beyond 98 mailing list subscribers.
I hope to add a design document with explanation and goals over the next day or so. Thanks, Philip On Tue, Jun 22, 2010 at 9:31 PM, Steve Wart <[hidden email]> wrote: My artistic ability is pretty much nil but I wholeheartedly support this idea. After getting back into Smalltalk after several years of OS X and iPhone programming it's not a stretch to say the user experience leaves something to be desired. |
Lawson On 6/22/10 7:58 PM, Philip Weaver wrote: Hi Steve, thanks for writing. |
Hi Lawson,
I am wanting to collaborate with a couple of people on UI mockups. But if you're also interested in coding now I'm sure that Dan, Robert, and Jens will find a way for you to contribute. I hope you're also interested in helping to re-imagine the user interface for Lively. Regardless I'll be sure to copy you on emails.
Below is just a start but I'll explain soon what more I hope we accomplish: http://tinyurl.com/lively-panel/
On Tue, Jun 22, 2010 at 10:41 PM, Lawson English <[hidden email]> wrote:
|
Thanks for the encouragement. What are the main organizational concepts in Lively? What are Areas, Workspaces, Packages and Classes? I am somewhat bemused by the way Javascript builds class-instance behaviour on top of a prototype system (although it's been a while since I read much about it, so I might be mistaken). Does Lively retain the idea of classes or is it purely a prototype system?
A friend suggested that Lively might be a good environment to learn Javascript but I'd like to have a better idea of how people manage dependencies among various libraries. It seems that managing a pool of *.js files also needs to represented. Does Lively let you mix and match other Javascript libraries? If so, would it be possible to add visual tools to help with this or is the fundamental browser model too restrictive for that?
Hopefully this isn't off topic or if I'm repeating FAQs. I think I might be able to help visualize things better if I understood them a bit more. Steve
On Tue, Jun 22, 2010 at 9:14 PM, Philip Weaver <[hidden email]> wrote: Hi Lawson, |
Hi, Steve --
Modules The main package entity for source cod in Lively is what we call a module. A module integrates several things: - It has a name and this name is used as a namespace when the module is loaded - A module can be loaded asynchronously on demand simply by referencing them with their name - A module include class definitions (also function and object definitions but we want to stick to the class concept whenever possible) (Note: Since a module namespace can be currently extended from anywhere, modules do not enforce encapsulation) Module Example module('lively.ide').requires('lively.Tools', 'lively.Ometa').toRun(function() { // Code depending on lively.Tools and lively.Ometa }); // end of module This definition does two things: a) Define the module lively.ide. The module can then be required from somewhere else: require('lively.ide').toRun(function() { new lively.ide.SystemBrowser().open() }) Evaluating this will let the system: 1. Check if lively.ide is loaded. If not then the module name is translated to an URL: {Config.codeBase}/lively/ide.js. That URL will be used to load the file ide.js asynchronously. * 2. When the file is loaded run the code of toRun() b) Define the namespace lively.ide. That means that if the module is there you can access it's members in JavaScript. For example the class lively.ide.SystemBrowser is such a member. ** For more information (module-file-mapping, how to get started in the wiki, etc.) please read: Classes Lively implements it's own class system implementation that was inspired by Prototype's class system. e.g. Object.subclass('Foo', { method: function() { return 23 }, }); new Foo().method() // --> 23 Lively implements a complete JavaScript IDE, it's main part is the System code browser. It can be opened using the WorldMenu.
It's definitely better to learn JavaScript in Lively than using in-place HTML scripting since Lively gives you immediate feedback (evaluate any expression in a Workspace or any other TextMorph with CMD+d (CMD+p to print the result). Managing files: see modules. Best, Robert
|
In reply to this post by Steve Wart-2
Emailing from phone. Back online in a day or so. Existing mockups
cover more than ide. They are maybe 10% complete and mainly for inspiration. An overview at this point and existing ide mockups are not necessarily accurate. Want to explore things like: zoom to morph, zoom to selection, morph navigation via the main column browser, multiple selection in a column stacks views in the next column, contextual menu as a single column column browser maybe for zoom to morph. Existing mockups need more simplification and some other solutions. |
In reply to this post by Robert Krahn
Hi Robert
This is very helpful. Thank you.
Steve On Wed, Jun 23, 2010 at 9:58 AM, Robert Krahn <[hidden email]> wrote:
|
In reply to this post by Philip Weaver
Yes I noticed that you've done a huge amount of work. I asked about the IDE because that is how I conceptualize the object model. Once I understand that hopefully all the rest of it will come together for me.
One thing that Apple insists on when defining the user experience for a new application is to come up with a clear statement of purpose. Not only what it is its intended user base (casual, professional, etc.), but also what it is explicitly not intended for. What *can't* Lively do?.
I've seen a couple of posts from Dan on his vision for Lively, but I still wonder, is it an educational environment, or is it something people can use to build commercial quality client-server applications?
Smalltalk evolved in rather unexpected ways I think. I don't think I'm looking for Lively on Rails, but I am interested in applications that appeal to mainstream development needs.
Steve
On Wed, Jun 23, 2010 at 10:54 AM, Philip Weaver <[hidden email]> wrote: Emailing from phone. Back online in a day or so. Existing mockups |
On 6/23/10 11:33 AM, Steve Wart wrote:
> Yes I noticed that you've done a huge amount of work. I asked about > the IDE because that is how I conceptualize the object model. Once I > understand that hopefully all the rest of it will come together for me. > One thing that Apple insists on when defining the user experience for > a new application is to come up with a clear statement of purpose. Not > only what it is its intended user base (casual, professional, etc.), > but also what it is explicitly not intended for. What *can't* Lively do?. > I've seen a couple of posts from Dan on his vision for Lively, but I > still wonder, is it an educational environment, or is it something > people can use to build commercial quality client-server applications? > Smalltalk evolved in rather unexpected ways I think. I don't think I'm > looking for Lively on Rails, but I am interested in applications that > appeal to mainstream development needs. > wrong. Lawson |
In reply to this post by Philip Weaver
[x-posting this to squeak-dev sand seaside dev]
Comment: Lively Kernel can be seen as a fork of Morphic. While the needs of an internet interface won't always be the same as the needs of a desktop-oriented application, it would probably be good for there to be some (at least semi-formal) examination by the Squeak world of what is going on in the Lively Kernel world. Anyone interested in Morphic's (and Tweak's?) future direction should be at least be monitoring that url below. Also, the documentation of LK might be suitable for use with Morphic, with suitable modifications. And of course, useful insights can go both ways. Just more of my B.rainS.torming.... Lawson On 6/22/10 2:50 PM, Philip Weaver wrote: Seventy-eight people are subscribed to this mailing list for Lively. Eighteen people are subscribed to the digest. I want to find at least one individual who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this on this mailing list alive daily. No coding involved necessarily and it ought to be fun and rewarding. |
In reply to this post by Philip Weaver
Inline...
On Tue, Jun 22, 2010 at 6:20 PM, Dan Ingalls <[hidden email]> wrote:
Grazie Dan. Keeping the dream alive!
I am interested in analyzing traits of among various kinds of controls: list with multiple selection ~= a column of checkboxes, list with single selection ~= a column of radio buttons, a column browser is potentially similar to a tabbed interface, Microsoft's ribbons are really just menus with a tabbed interface, a hierarchical menu is essentially a compact column browser. I don't have much more to say about this tonight so I'll probably just draw.
I do understand how this looks. Maybe someday I'll change my email address from philmaker to troublemaker. ;-) Again, Google Drawings does export to SVG.
These are just some highlights for improving vector illustration support in Lively: * shape library * shape/morph copy and paste support
* shape/morph undo support * rework morph selection to be more modern (e.g. do not immediately pickup a morph on click) * snap to grid, guidelines * grouping, locking, visibility, ordering (send to back, send to front)
* continue to refine the styling panel (possibly begin with: the hundreds of tiny swatch morphs are very slow on old hardware) - Philip
|
In reply to this post by Steve Wart-2
Hi Steve,
On Wed, Jun 23, 2010 at 1:33 PM, Steve Wart <[hidden email]> wrote:
I'd also consider the role of a user. Is the user primarily a consumer of content or a producer of content? Lively allows both at the same time. Sadly, most people in the world today are primarily consumers and not programmers. I don't have a final answer here but read on further below. Intended user base is indeed worthy of discussion.
I have interest in pursuing both of these but lean toward the latter, commercial development: I want to focus on whatever goals will help sustain and provide funding for this project. I wish and hope that Lively will become a disruptive technology to transform web development and web graphics creation. 1. Browser brings the history and bookmarks. 2. The toolkit brings it's own rendering and layout: whether it be the Lively Kernel or other. Web standards? Just say no. Use a canvas instead and your own toolkit. Also relating to graphics development: just say no to splicing raster images for web display: render them in Lively.
So for intended user base maybe: 1. professional "web" developers but retrain them, 2. education Some of the early Lively collateral discusses making web programming simpler without HTML, CSS, DOM, etc. The problem has been that Lively has not had enough layout support to realistically compete or replace HTML and DOM.
Philip
|
In reply to this post by Philip Weaver
So far I think I'm still drawing all by myself. :-( Would you like to make some drawings?
You can draw in the Lively wiki or you can draw in Google docs. A picture is worth a thousand words. Don't forget that if you'd like to code, please talk to Dan, Robert, or Jens. Thanks, Philip http://tinyurl.com/lively-mockups/ On Tue, Jun 22, 2010 at 4:50 PM, Philip Weaver <[hidden email]> wrote: Seventy-eight people are subscribed to this mailing list for Lively. Eighteen people are subscribed to the digest. I want to find at least one individual who has interest in contributing to UI mockups for Lively's future and to help keep conversation related to this on this mailing list alive daily. No coding involved necessarily and it ought to be fun and rewarding. |
Free forum by Nabble | Edit this page |