Re: OSX on Intel Could Destroy Microsoft

In article <znu-D13C64.21235226112005@xxxxxxxxxxxxxx>, ZnU <znu@xxxxxxxxxxxx>
wrote:

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

Yeah, well, I suppose.

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

But doesn't achieve the same goal. Generally, the downloadable javascript
libraries that handle date input doesn't do it good and is still hindered by
the limitations by the web browsers. It's no different than if I would do it
myself. For instance, for the date picker, no javascript library allows me to
display a clock face and have the user set the time by dragging the clock arms
around to the correct time - like the OSX control panel lets me.

Plus, go to the Date & Time control panel - apart from the obvious
point-and-click interface, you've got a special input box that's divided into
parts, where you can only select a specific part at a time and set it - this
gives greater control of the output.

I am currently handling date/time input by language parsing, where the user can
actually type "friday next week" in the date input field and it's translated to
a ISO date format.

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

Yes, that's nice - but I still need to develop for the lowest common
denominator - IE.

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

True - but I also have a CSS editor with built in templates from which a client
can work from. BUt I see your point.

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

Not the login part - it's consistent over all my sites - but the registration
part is a whole other deal. Each site has its own needs for what information
they want members to supply when registering and what information they should
be able to add/edit. My system handles this with a form builder component - my
client can specify exactly what kind of information they should submit.

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

Actually, no. I request like that generally is about "Yeah, I don't like how
this page look and handles calender events, I want it to look like this" -
Since it deviates from the standard look, I just develop a client-specific
"look" which is tied to the same backend database as the original.

For instance - I built a recruiting system for members which is a general
system within Atlas, and it merely looks like this:

<http://www.malarnetcity.se/member/functions/recruited.php?id=12144&lang=en>

BUt in this project, the client wanted to tie a contest to this, so I built a
front end for the data that looks a bit different:

<http://www.malarnetcity.se/sidor/recruit/>
(Sorry, no english version of this)

But that has happened once or twice - generally my system is flexible enough to
handle most needs in this regard. For example, one client requested that a
bransch index (I hope that's the right word) should be tied to the member
profile, which didn't allow anything like that. I just wrote that as a member
profile plugin which is easy to enable in the admin interface.

> What if a client wanted users of the site to be able
> to maintain their own pages, for instance?

Yeah, that's pretty common in a community. I really don't know what you mean by
"maintain", but the most extensive use of the community functions in Atlas is
the above site, where users can do lots of stuff:

<http://www.malarnetcity.se/member/info.php?id=5879>
(My own profile page)

What you see there is the weblog part of the profile - the icons at the top go
to different parts of the profile page. Append "&lang=en" to the URL to get a
translation of them (but most content will disappear).

All of those icons are profile modules. This is a city community, so companies
can also have profiles:

<http://www.malarnetcity.se/member/info.php?id=7770>

Which look quite different. You'll even note that one of the profile modules is
even a webshop, tied to that member. All of these standard modules can co-exist
with client-specific modules as well - and the site admin decides what modules
are available to what member type.

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

Exactly - my system has four different kind of users:

Unregistrered or not logged in.
Logged in
Logged in and part of an access group
Logged in and has admin privileges to one or more modules

Basically, I have a front-end edit-system for members so they can edit their
own material such as weblogs, forum entries, comments and stuff like that. Then
I have a more comprehensive back-end admin interface that can do a lot more.

You can actually try all of this out if you register at csma.sandman.net. I
have done very little to customize any of that site, but you could get a hang
of it anyway.

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

Ok, will that red-flag the todo (or something like that) if it isn't completed
on time? For a todo list, this seems like a rather important thing. Anyway, not
to say that basecamp is bad, it looks very good, I just missed some stuff.

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

Agreed.

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

Unless you consider that the new-data form need to be located in a manner that
it's readily discoverable, and with my philosphy that action buttons should be
at the top (apart from navigation buttons, which should be at the top AND the
bottom), having it open uup a hidden layer at the bottom might be a bad idea,
plus if you open it up in an absolutely positoned hiudden layer, you're doing
pretty much the same thing as a popup. At some places I've done it as I have
with this hidden search form:

<http://www.malarnetcity.se/atlas/calendar/list.php&lang=en>

Hit the search button and the form appears. Plus, you get a very sleek looking
calendar list, and more information of each event is hidden either by clicking
(which opens the info in a popup), or by hitting the triangel to flip out more
information.

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

That's insane - my two monitors are crowded. I could actually use a third :)

But the ability to arbitary reorder windows in pro apps is important, to me.
Motion is a nightmare to use because you constantly have to deal with making
the canvas view smaller if you want to make the layers view bigger. I very much
prefer Final Cut Pros approach to this.

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

Imagine PhotoShop not having palettes at all, but rather folding "views" in a
grand master window. Ouch!

Generally, I don't want someone else to decide where my layer palette should be
positioned on screen for me, especially when I have dual monitors.

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

But it adds to the confusion of the user, if the "new item" button isn't even
discoverable without a certain amount of scrolling. This is - to me - bad UI. I
rather solve it like I do with the calendar view.

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

Which is good! Having controls atteched directly to the data is a good thing -
but not at the expense of discoverability.

Atlas - for instance - pops up edit controls whenever your mouse hovers over
something editable:

<http://jonas.eklundh.com/texter/read.php?id=44050>
(it's the line of icons at the right)

That one is for the articles, where each icons adds/edits images, links, files,
votes and notes attached to an article.



--
Sandman[.net]
.

Loading