Re: OSX on Intel Could Destroy Microsoft

In article <mr-7E373C.00350827112005@xxxxxxxxxxxxxx>,
Sandman <mr@xxxxxxxxxxx> wrote:

> In article <znu-AF5581.15184025112005@xxxxxxxxxxxxxx>, ZnU <znu@xxxxxxxxxxxx>
> wrote:
>
> > AJAX in the wider sense I'm referring to is being used to do all of
> > those things. In some cases, people are writing libraries that allow web
> > developers to implement those things with a couple of lines of code,
> > without needing to worry about browser compatibility issues. These
> > libraries are even being integrated with web application frameworks, so
> > developers don't have to mess with JavaScript at all, and this more
> > advanced client-side functionality seamlessly integrates with the server.
> >
> > For instance, if you're writing a web app in Ruby on Rails, you can make
> > a list re-orderable via drag-and-drop by simply sticking:
> >
> > <%= sortable_element("my_list", :url => { :action => "order" }) %>
> >
> > into your template file. This handles all the client-side JavaScript,
> > and when a list item is moved, the 'order' action of the current
> > controller will be called asynchronously on the server with the new
> > order of the list items as a parameter; a couple lines of code in that
> > action can save the new order to a database.
> >
> > Setting up draggable items and drop targets for them is as simple as
> > sticking things like:
> >
> > <%= draggable_element("my_image", :revert => true)
> >
> > and
> >
> > <%= drop_receiving_element("my_cart", :url => { :action => "add" }) %>
> >
> > into your templates.
> >
> > There's no JavaScript date picker in the core libraries yet, but if you
> > install <http://projects.exactlyoneturtle.com/date_picker/>, you can get
> > a neat little date picker by just sticking something like:
> >
> > date_picker_field('event', 'date')
> >
> > into a template.
>
> Generally, I think this is a bad idea, since you're relying on third party
> solutions and that they are updated properly.

Well, sure, but this stuff is fairly simple, and you've obviously got
source, so you can always just dive in and modify it yourself if it
becomes necessary.

> But apart from that, these are all hacks to work around the stupid
> limitations of web browsers. Welcome ones of course, but nevertheless
> hacks.
>
> There should be something like this:
>
> <select reorder="true" alternate="true" width="300" height="200">
> <option value="sf">
> <column>San Fransisco</column>
> <column>10 pm</column>
> </option>
> </select>
>
> That would result in native list object with column support and so on.
>
> And:
>
> <date time="true" />
>
> For a date picker that would look exactly like the one found in System
> Preferences, maybe expands when selected.
>
> <file type="image/jpg" width="100" height="24" background="pic.jpg" />
>
> For a file drop area.
>
> And so on.

Whether the browser limitations are 'stupid' depends on what you see as
the proper role of the browser. Browsers do not presently provide an
extensive library of complex UI elements. What they provide instead is a
set of primitives which can be used for, among other things,
constructing such elements. Of course, each web developer shouldn't be
required to re-invent the wheel, which is why such elements are now
being standardized within web application frameworks. Arguably it makes
much more sense to put them there than in the browsers themselves; it
gives everyone more options, and keeps clients light-weight, which is
one of the major benefits of this new approach.

Of course, there are some cases where browsers just don't provide
sufficiently advanced primitives to create certain UI elements. These
are being addressed, though. The Canvas tag, now supported in Safari,
Opera and Firefox (1.5) is an example of this.

> > > But a necessity. One could claim that it would be better for cliients
> > > to purchase different specilized tools for specific functions of
> > > their web site - like forums, project management, news, calendar,
> > > mailinglists and so on. But most my clients still value a
> > > single-login system with a consistent UI (albeit, a
> > > different-than-dekstop UI).
> >
> > Well, yeah, the idea of high-level components that integrate
> > automatically is even more of a pipe dream than the idea of of a general
> > purpose CMS.
> >
> > You can certainly build a CMS that works for specific types of web sites
> > -- say, "Slashdot-like news site". Building a CMS that allows someone
> > with no programing skills to build whatever they want, on the other
> > hand, is impossible.
>
> I disagree, it all depends on how flexible the system is. My system
> works from layout templates, which are generally created once, and
> from which my clients can work with. I.e. they generally don't change
> the layout of the site, but are free to compose their content pretty
> much how they want.

If you're talking about users just plugging content into a pre-existing
site layout and structure, yes, that's perfectly reasonable. But that
pre-existing layout and structure has to be created by an actual
developer, and has to be specific to the type of site the user wants to
run.

Even things that seem like they could be relatively standardized across
site types, like logins, often can't be, when you get right down to it.
A standard log-in component can provide a starting point, but will often
need to be customized, frequently in ways that will fork it from the
original code base (not just by subclassing parts of it, for instance).

> But dealing with dynamic data in a "arbitary user layout" environment
> is hard, indeed, so some conformance to a specific layout is
> expected.
>
> > > CMS systems really is the next logical step (and has been for
> > > several years now). People rarely want to do projects out of
> > > their web sites that they give to advertising agencies - they
> > > rather invest in a system that gives them the control.
> >
> > Just because something would be really, really useful doesn't mean
> > it's actually possible to implement decently. It's practically
> > inevitable that no matter what you do, the first actual client you
> > try a system on will, within 10 minutes, ask for something it
> > doesn't do.
>
> All the time - which is why my system is a ongoing project and not a
> software solution I install at a specific version. I host all my
> clients on my Atlas server, and all former clients benefit from new
> functions requested by from newer clients. It's really the best
> solution, resource wise, given that I am the only person working on
> this project :)

Now the tricky part is when someone asks for something that the existing
system doesn't do that's really hard to implement within the existing
structure you have. What if a client wanted users of the site to be able
to maintain their own pages, for instance? I don't know, maybe you've
already got that covered, but it's not too hard to see how adding
something like that could be a major issue for a system that wasn't
written with that requirement in mind. The entire login and permissions
system might need to be re-worked, for instance, or the editing
interface might need to be modified to protect the site against
malicious users (by e.g. blocking certain tags), etc.

[snip]

> > Maybe that's true. But tens of thousands of people are. Basecamp
> > was mostly written by one guy; it could probably be re-implemented
> > by someone else in a few weeks. Yet a large number of people find
> > it more useful than, say, Microsoft Project.
>
> I have no doubt. Only a small percentage use the full potential of
> Atlas - most just want to publish news on their web site. But I just
> got a little surprised in to do-items not even having a deadline, and
> things like that.

You can associate to-do items with milestones.

> > This is the new model. It doesn't replace the old model outright; but it
> > does provide a new way of thinking about how to design and deliver apps,
> > which, as I said previously, allows an escape from the baggage
> > traditional desktop apps have accumulated over the last couple of
> > decades.
>
> Which is both good and bad, I'd say. :P

Well, sure, isn't it always? But there's definitely something going on
lately, and it extends beyond just web apps. Take a look at
http://www.fastcompany.com/magazine/100/beauty-of-simplicity.html

I'd say 'simplicity' and 'openness' are the two big things happening
with tech today; you see them both popping up everywhere.

(Microsoft is noticeably bad at both of these things.)

> > > > Moreover, as applications have gotten bigger, and as users have
> > > > started multitasking more, some desktop concepts just haven't
> > > > scaled very well -- like tossing windows and dialogs all over
> > > > the place. We're seeing desktop apps pick up a lot of UI queues
> > > > from web apps -- like actually laying out single screens to
> > > > provide multiple views, instead of sticking each view in its
> > > > own window and leaving the user to figure things out.
> > >
> > > Argh! Soon you'll be a MDI advocate :-D
> >
> > Consider how iMovie works. In 1995, you'd have written the app with
> > a viewer window, and a timeline window, and clips window, and an
> > effects window, and so on. The user would arrange these on the
> > screen, open and close them from a 'Window' menu, and so on. iMovie
> > sticks all of this in one window, already laid out for the user, so
> > window management is no longer a task the user needs to worry
> > about. I'd say this is pretty clearly influenced by web layout
> > techniques.
>
> Right, but iMovie is supposed to be easy - so one-window makes sense
> for the reasons you state above. And really easy web apps such as
> basecamp may also benefit from the one-window dogma, but I would
> still argue that some web apps would benefit from a multi-window
> approach.
>
> Atlas, again, does this in more ways. If you log into a Atlas-based
> community, you can open a "news" window, which will show you what has
> happened since last you opened that window, all aggregated into one
> view (articles, forum topics, comments and so on). This opens in a
> smaller popup window and all links within it opens in the parent
> window so it's more like a utility palette for the community
> application. This is, again, one way to achieve the same function
> that AJAX does.

With, I'd argue, more clutter, and less smooth workflow. (Popping up a
window for data input and then reloading the main page is much more
jarring than just taking new data input in context.)

> > Aperture and Motion use this approach as well, so it's not just for
> > consumer apps.
>
> BUt it's *wrong* for MOtion and Aperture to do it. I hate that I
> can't put the layers palette on my second monitor. When I'm using
> Motion, tons of screen space is *wasted* because I can't move stuff
> to the second monitor, apart from the library/attributes views.

Multiple monitors aren't as useful as they used to be, in these days of
massive screens. I've got a 1920x1200 screen and a 1280x1024 screen --
the smaller one stays off 90% of the time, because it's just not useful
for most tasks. I know you've got two 30" displays -- I have no idea
what you use them for, honestly.

I don't agree that this new approach is only suitable for consumer apps.
It's all about managing complexity, which is something everyone needs --
pro users working with e.g. huge image libraries or projects with
hundreds of elements might need it *more* than consumers.

> > Even Final Cut Pro, which does still use multiple windows for these
> > sorts of things (its UI is a bit older), doesn't really treat them
> > much like normal windows. You generally leave all the commonly used
> > windows open all the time, and you usually let the app lay them out
> > for you.
>
> But on multiple monitors.
>
> > > That aside - my approach to AJAX is to use popup windows
> > > actually. When in the calendar, and clicking 'add calender event'
> > > will spawn a small popup that enables you to fill out the
> > > required data, and when you press submit it inserts it into the
> > > db, closes the popup and reloads the main window. Ok, so it's not
> > > AJAX, but serves the same function more or less.
> >
> > Might be a little more seamless to do something like what Basecamp
> > does when you add a To-Do item.
>
> I don't like to show/hide a form at the bottom of what could be a
> very long list. I always place actions at the top of the page, much
> like the toolbar icons in OSX.

I'd say this is another web/desktop UI split, yes. Desktop interfaces
tend to cluster actions together; they all go in the same place by
virtue of all being the same type of thing. Web interfaces, in contrast,
tend to place actions in context; placing a 'new item' command at the
bottom of a list makes sense because that's where the new item will be
added. This is another case where recent desktop apps are borrowing from
web interfaces.

Another way to think of this is, the traditional desktop metaphor is
that you've got a set of tools which you use to manipulate a passive
document. The new metaphor is, you've got a document (well, that's not
quite the right word, actually) with its own embedded functionality.

It's easy to see why the former metaphor was chosen in the 80s; it's a
good mapping of how people create things in the real world. The new
metaphor is more abstract; conceptually it's sort of like
object-oriented programing -- you ask data to manipulate itself, rather
than using an external function to manipulate it. And, of course, the
purpose is exactly the same as with object-oriented programing; it's all
about managing complexity, by narrowing the scope of factors the human
trying to get work done needs to worry about in each context. Instead of
a menubar or toolbar with dozens or hundreds of items, you're
encapsulating functionality into small, simple, stand-alone 'objects',
like a list of to-do items and associated actions.

--
"It's in our country's interests to find those who would do harm to us and get
them out of harm's way."
-- George W. Bush in Washington, D.C., April 28, 2005
.

Relevant Pages

  • Re: OSX on Intel Could Destroy Microsoft
    ... people are writing libraries that allow web ... layout templates, which are generally created once, and from which my clients ... > does provide a new way of thinking about how to design and deliver apps, ... > viewer window, and a timeline window, and clips window, and an effects ...
    (comp.sys.mac.advocacy)
  • Re: start Application in a Window
    ... window. ... Jens wants, though, since it hasn't been described well at all. ... Many X apps take the -geometry option. ... to group a set of X clients together so that you can move all the X ...
    (comp.os.linux.x)
  • RE: Make a window "Click-through"
    ... I guess the functionality you desire could be achieved with ... I've got two little apps which are able to create a window that displays ... click on the window, the item 'behind' or 'under' that window gets clicked. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: OS/2 mentioned in a Vista review
    ... Although other applications can continue to paint themselves (no window message blocking), I'm sure a rogue app can still claim ownership of the mouse and keyboard and not give it back. ... Consider full-screen apps. ... Audio subsystem doesn't sound like anything better than DSound or DART (OS/2) in terms of resolution and response time. ... I'm doing more with my computers than ever before. ...
    (comp.os.os2.misc)
  • Re: OSX on Intel Could Destroy Microsoft
    ... >>> Online Shopping interface that web sites could adhere to. ... AJAX is a way ... But most of the web apps out there can, ... Well, sure, because you can put anything you want in a window in a ...
    (comp.sys.mac.advocacy)
Loading