[ruby-talk:6123] Re: What would a Ruby browser look like? -- It's Just a View!

On Tue, 7 Nov 2000, Conrad Schneiker wrote:

> Hugh Sasse thundered from Mt. Olympus:
> 
> > People are already talking about using Tk to do this, or doing it as a WWW
	[...]
> > Please let's think about what this will DO before we think about what it
> > will *look* like. :-)
> 
> Well, if you check the order of all my preceding posts, I think you will see
> that the issues were raised in that order. But what you dismiss as "just"
> views can have a tremendous impact on whether users like the system or not.

Yes, agreed: my point here is: We do need a good interface, but we need
a good underlying model first, so that we are not restricted by interface
based assumptions.

> And since the primary purpose of proposing this project was to promote Ruby,
> it had better be a likable system, regardless of how cosmic its abstract

Also agreed.

> design is. I think it's also a safe bet that 90+% of the potential market
> for such a system doesn't want a pure text interface or a Morse Code
> interface. It doesn't hurt to have a rough idea of what practical
> constraints you will likely face.

True, but those with text only access, or worse, are also potential users
of ruby, who are not excluded at present.  Let's keep them on board.
> 
> (There are a few pairs of applications that readily come to mind that
> essentially DO the same thing in approximately the same ways, but where one
> of each pair is very obnoxious to use and the other of each pair is nice to
> use, mainly due to what appears to have been greater concern with look and
> feel from the outset.)
> 
Yes, interface is important, and should not be neglected but I believe
we should defer decisions on while we can.

> > One of the ideas of XP is don't decide now what you can decide later.
> > Also concepts like "Accessibility" and "Universal Design" come to mind.
> 
> Well OK, if we are going to all be driven to worship the golden calf of XP,

No, just take the bits from it that are good.  Don't stick to one
methodology except where it helps.

> doesn't that involve some degree of incremental implementation-informed

Yes, it would.
> design? And test as you go. Seems kind of hard to test an OO browser without
> some means of putting up pixels--at least for a mere mortal like me. And

:-) I wasn't saying "Don't makey any interface at all", just keep it in
its proper place.  And keep in mind that there may be more than One True
Interface.

> some real-world concepts like "Practical", "Limited Resources",
> "Cost/Benefit", and the "80-20 Law" also come to mind. (Not to mention
> barging their way to the front of the pack :-)
> 
> So anyway, what do you want it to do?

I'd like it to show some navigable structure of classes, including
mix-ins. You can get details of the one class/instance you are interested
in, and "see" where it lives in relation to others.  Searching would be
useful too.  It would be really good if it could be tied into debugging
environments, so that as one's program genreates objects, and "reaps"
them, one can see what they are.  That suggests some kind of hooks
that the programmer can take advantage of, perhaps.
> 
> Conrad
> 
	Hugh
	[e-mail]