Re: Maybe Safari 4 actually is for Windows

In article <VIqdnRzHsJZ15TXUnZ2dnUVZ_o7inZ2d@xxxxxxxxxxxxx>,
"Dan Johnson" <danieljohnson2@xxxxxxxxxxx> wrote:

"ZnU" <znu@xxxxxxxxxxxx> wrote in message
news:znu-10641A.11080927022009@xxxxxxxxxxxxxxxxxxxxxx

[snip]

Creating tabs from right to left wouldn't feel that awkward if you
were doing it by clicking a button on the left of the tab area. But
I think it would feel very awkward when creating a tab by
command-clicking a link. Take the not-too-unusual case of a user
command-clicking a bunch of links while reading a page, to load
them in the background to read a little later. If tabs were created
from the left, you'd have to move right to left along the the tab
bar to access each of those pages in the order you loaded it in,
which just feels wrong.

On could create tabs on the left only when it would make sense, I
suppose.
:/

Creating tabs on different sides depending on what command created them
would be even more awkward.

Or maybe OS X needs to move all its window controls to the right! :D

Good luck with that. (IMO window controls feel more natural on the left
for left-to-right language users as well. The fact that they're on the
right in Windows appears to be one of those cases where Microsoft just
use the opposite positioning that Apple did to make their UI
"different" back in the days when there was still some shame in blatant
UI design theft. See also: default positioning of desktop icons,
putting the taskbar at the bottom of the screen so it doesn't look too
much like the Mac's universal menu bar, and "Recycle Bin" vs. "Trash".)

[snip]

[snip]

(The iPhone UI also largely jettisons selection and indirect
manipulation, perhaps because direct manipulation feels much more
natural when you're "touching" the interface.)

I note that 'inline buttons' are *not* what is usually meant by
'direct manipulation'. Those buttons are separate controls from the
things they manipulate.

If you don't like the work "direct manipulation", perhaps we could call
it "in-context manipulation". It's still quite distinct from the model
of selecting an item and then choosing a command, off on another part
of the screen, to modify it.

[snip]
May I ask what apps are better served by the web's "UI
conventions", if indeed it has any?

Go play around with Basecamp, if you haven't (they offer free
accounts), and tell me the functionality it provides would actually
be more easily accessed through some UI with a bunch of windows, a
couple of toolbars and a couple dozen menu commands.

Perhaps you could explain it to me, instead of expecting me to figure
it out on my own?

Let me see if I can articulate this better. Web apps largely break down
the traditional barrier between data and tools, instead utilizing what
we could call "smart data". Automatic persistence at uniquely
addressable locations in the cloud, the fact that editing functionality
comes along with the data automatically, and web UI conventions like
in-place editing, all contribute to this.

To some extent, I hesitate to even call something like Basecamp an
"application". Consider the fact that virtually every "screen" in
Basecamp lives at a unique URL. If I want to refer you to a to do list,
I can send you a link. You can click that, and the list will load in
your browser. This isn't "application" behavior, this is web page (i.e.
data or document) behavior.

While Basecamp is obviously an application in the technical sense, it's
*not* an application if one considers things slightly more abstractly.
A Basecamp project is just a collection of web pages that document a
project. They just happen to be "smart" pages that contain embedded
tools for modifying their contents in useful task-specific ways.

This is a significant conceptual difference from the typical
application/data model, and it works very naturally for certain types
of tasks.

[snip]

Despite Google having long offered APIs that would allow for it,
nobody seems all that tempted to put a desktop UI on Google search
results.

You couldn't really do it without bringing Google's indexes onto your
local disk.

Err? We're talking about desktop vs. web UI. You'd create a desktop UI
with web-sourced data easily enough.

And you'd have to find a way to keep the ads in. That's the whole
point for Google.

This is also a pretty easy problem. Apple's old Sherlock search
application used to display ads from the web search engines it
dispatched queries to.

I think the reason there aren't lots of contemporary desktop front-ends
for Google search results pages is just that there just isn't anything
wrong with Google search results pages that could be substantially
improved by creating a desktop UI.

[snip]
I haven't used it, but note that MS is trying to do this very
thing with their Office Live Workspace thing.

At the cost of requiring a compatible version Office to be
installed for document editing, right?

Yep. But you do get a lot of capability for that.

You get a lot of capability related to the creation of complex
documents.

But here's the key issue: most documents aren't that complex. Many
internal business documents (perhaps *most*) are a few pages long, have
no complex formatting, and may never even be printed. Google Docs works
fine for this sort of thing. In fact, it works *better* for this sort
of thing, because of the low-overhead sharing and precisely because
it's a much simpler tool with many fewer features.

[snip]

What *should* happen is that document-based desktop apps should
routinely support opening documents directly from and saving
documents directly to URLs. And preferably have live collaboration
features, if multiple people open the same document at the same
time.

There's no reason they can't do this, and they are evidently working
on it.

Microsoft may be working on in the context of a specific suite of
applications. This is not a general solution to this problem.

[snip]

It's rather optimistic to say ClickOnce addresses this. Making it
mildly easier to install desktop apps doesn't change the fact that
they still have to be installed and maintained on the user's
system, with all of the overhead involved there.

This isn't any more true than for a Flash app or an HTML page.
There's a local copy, but it's updated automatically.

Um... surely you're not claiming that a "local copy" of a
gigabyte-sized software suite which consists of thousands of files in
various locations, probably hundreds of registry entries, and
integrates with various other apps on the system, is actually
equivalent to a few kilobytes of HTML and JavaScript sitting in a web
browser cache.

[snip]

QT does not support WMV out of the box.

They're not compatible.

Managed to track this down. WMP12 (which I'm sure will be extremely
common by the time HTML 5 is widely supported enough to be usable)
includes H.264 support out of the box. So we've got our common codec
right there.

--
"What the cynics fail to understand is that the ground has shifted beneath them
? that the stale political arguments that have consumed us for so long no longer
apply. The question we ask today is not whether our government is too big or too
small, but whether it works [...]" -- Barack Obama, January 20th, 2008
.

Loading