Re: Maybe Safari 4 actually is for Windows

"ZnU" <znu@xxxxxxxxxxxx> wrote in message news:znu-45B6F2.11085128022009@xxxxxxxxxxxxxxxxxxxxxx
In article <VIqdnRzHsJZ15TXUnZ2dnUVZ_o7inZ2d@xxxxxxxxxxxxx>,
"Dan Johnson" <danieljohnson2@xxxxxxxxxxx> wrote:
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.

Perhaps it's not an ideal proposal...

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.

I think you are just used to the Mac way. It's not like it bothers anyone on Windows.

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.

Well, no. They put their system menu on the left back in the day, and that doubled as the close box.

When Win95 came along, they put a real close box on there, and since the left edge had the system menu, they put the close box on the right. Putting them next to each other would be obviously dangerous. Of course, putting close next to minimize and maximize is dangerous too, but they'd run out of ends of the title bar.

Back in The Good Old Days, classic Mac OS had the close box on the left, and the other stuff on the right- well separated. That made sense. I still don't understand why Apple abandoned this. I can't see what OS X has gained by lumping all the widgets on one end of the title bar. It's not like you've got a system menu to squeeze in there.

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

Hey, that last one's just truth in advertizing. It doesn't destroy the files, it just reuses the disk blocks! :D

[snip]
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.

I do not know if it is really different in any important way; it's just a question of how close the controls are to the selection. And it's not like they don't get really close in a desktop UI, either: consider Office 2007's font/style popup thing. That appears right next to the selection, wherever the selection is.

[snip]
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.

I see nothing here that distinguishes web-apps from normal apps, except for the overused buzzword "cloud", which as far as I can see, just means "internet".

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.

You do get this behavior with applications too. OLE does this. Admittedly, those
aren't URLs, but the principle is the same.

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 does not shed any light on anything.

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

I just don't see it. It looks to me like web apps are like desktop apps, only not as good in most respects due to the limitations of the platform they are running on, to wit, the web.

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

You can, but you can't query it in the fluid way Spotlight does unless you bring it local. The internet's latency is killer.

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.

Did it do Google?

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.

Google's web page works, but it's still poor UI compared to what is routinely done on the desktop. There may not be a real need to improve Google's web page, in fact, but the difference is pretty stark nonetheless.

[snip]
> 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.

Yep, that. Also, good UI.

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.

This is a theory which has led to many unsuccessful Office programs.

It is true that most documents do not require the full power of Microsoft Office. Each one uses a small subset of the total features. But there is a great diversity of documents in the world, and a 'just-what-you-need' Office product is generally suitable for only a small subset of them.

There's not a lot of people who would just settle for WordPad.

[snip]
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.

A 'general solution' to collaboration?

I don't think anyone has that.

[snip]
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.

If Office were a web site, it would not be a *small* web site.

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

We'll see. If it actually works like that, you get the thank Microsoft for it, though.


.

Loading