Re: OSX on Intel Could Destroy Microsoft

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. 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.

> > 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.

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 :)

> A more realistic approach to building web sites faster, better and
> cheaper is to optimize developer productivity, rather than trying to
> eliminate the need for a developer.

Well, since I am self-employed, and don't have any employees, it's in my best
intrest to put as much control into my clients hands as possible, so they don't
have to call me to get X and Y fixed, only Z.

> > 1. Great tutorial "mode"
> >
> > 2. It's *extremely* basic and limited.
> >
> > Anything that has few functions is going to be easy to use. But my
> > clients wouldn't really be satisfied with Basecamp.
>
> 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.

> 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

> > > 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.

> 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.

> 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.

--
Sandman[.net]
.

Relevant Pages

  • Re: OSX on Intel Could Destroy Microsoft
    ... >> advanced client-side functionality seamlessly integrates with the server. ... gives everyone more options, and keeps clients light-weight, which is ... >> does provide a new way of thinking about how to design and deliver apps, ... >> a viewer window, and a timeline window, and clips window, and an ...
    (comp.sys.mac.advocacy)
  • Re: Direct3D Windowed Device... Other Windows Not Repainting
    ... Are you sure you're not painting over the toolbars you have (3D rendering ... All clients are laid out from ... > When I resize the layout window by dragging its borders, ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: WSUS - installed but no computers are using it
    ... there is any DNS resolution issue on the clients. ... Test if the client can receive new updates from the SBS server now. ... click to check the "Hide All Microsoft Services" ... Click OK to close the MSConfig window. ...
    (microsoft.public.windows.server.sbs)
  • Remote Desktop Web Connection- - how to disable IE window reuse?
    ... page that uses the MSRDP ActiveX control. ... problems with this is at some larger clients their domain Group Policies ... We have begun opening our window ...
    (microsoft.public.windows.terminal_services)
  • Re: disable double click to change window size
    ... I suspect we're not all that far apart in how we approach apps for clients. ... that forced maximizing would never get past a demo run. ... maximum window space available. ...
    (microsoft.public.access.modulesdaovba)