Re: Apple's poor positioning for the age *after* x86

In article <2005092318012316807%danieljohnson@vzavenuenet>,
Daniel Johnson <danieljohnson@xxxxxxxxxxxx> wrote:

> On 2005-09-21 21:39:55 -0400, ZnU <znu@xxxxxxxxxxxx> said:
>
> > In article <2005092118273643658%danieljohnson@vzavenuenet>,
> > Daniel Johnson <danieljohnson@xxxxxxxxxxxx> wrote:
> >> I'm not buying it. I also don't think this will scale- the vast
> >> majority of pages will just not be ranked at all.
> >>
> >> I think Google's way is just plain better (tm).
> >
> > You might want to listen to this:
> > http://www.npr.org/templates/story/story.php?storyId=4856924
>
> No thanks. It's NPR, and therefore boring. :D
>
> > Google's automated approach is the only practical one if you hope to
> > index and rank the entire web. But maybe we need to reevaluate what's
> > really useful. The real problem with web searches today is not that
> > they don't return enough good results; it's that they return good
> > results mixed in with millions of useless results. Community review is
> > a way of solving this problem.
>
> Google's ranking system is a way to solve this problem, and a pretty
> good one in my view. You might argue that Google is solving the wrong
> problem in trying to index the entire web, but if you come up with a
> different problem and solve it, are you still competing with Google?

The larger problem is still 'Help people find useful stuff on the
Internet', so yes.

> [snip]
> >>> Product catalogs, mailing list archives, Wikipedia entries.... I
> >>> wouldn't be surprised if more than half of the public content on the
> >>> web was hidden behind search boxes that traditional crawlers can't see
> >>> past.
> >>
> >> It seems to me that Wikipedia is already pretty well indexed by Google.
> >> I can see how vendors would want their catalogs indexed "more", but
> >> it's not clear that this would make Google better for its users.
> >
> > The API wouldn't just allow Google to do full-text indexing of the
> > contents of databases, it would also allow Google to make more sense of
> > data on the web; we discussed mining web pages to produce structured
> > data previously; that's a tricky problem. On the other hand, much of
> > the information on the web already *is* structured, but software can't
> > see that from looking at HTML pages. That structure *could* be exposed
> > through this API.
>
> What structure are you thinking of?

What's a product page. What's a product price. What's a spec lsit.
What's a blog post. What's a blog post archive, and what's an entry
within that archive. What's a message board, and what's a message....

The list goes on practically forever. Right now, Google has a poor under
standing of semantic units smaller than a 'page'.

> > This would allow people to, for instance, *exclude* product catalog
> > results from their searches.
>
> Ah, now *this* is not something that vendors who publish catalogs would
> desire. They would not use the APIs if such were the result, I think.

If they didn't use the API, their results wouldn't pop up when people
performed explicit product searches. Sacrificing that to have your
products come up when people explicitly *aren't* looking for a place to
buy would not be very clever.

> >> I'm not sure how mailing lists fit into all this.
> >
> > Most mailing lists maintain web-based archives. Just an example of the
> > sort of thin Google might not be able to see right now.
>
> If they are web-based, and public, Google can see them, I should think.
> What's not to like about indexing them like web pages?

For one thing, you'll often end up with totally irrelevant results
because your result set will include some pages that have unrelated
posts which, combined, happen to contain all of your keywords.

> [snip]
> >> MS could have used MFT indices or something like that, but that would
> >> have been even more fragile.
> >>
> >> MS could have used cryptographic hashes to prevent this, but it seems
> >> like a lot of complexity when a much simpler approach is available.
> >
> > Apple has always dynamically detected these sorts of things, and when
> > it looked like this might pose a security threat, they leveraged the
> > mechanisms they already had in place for the Keychain to simply pop up
> > an alert the first time a new or modified app was run.
>
> I think this rather confirms what I said: Apple uses a more dynamic,
> "find it anywhere" approach and this leads to a security vulnerability.
>
> > (Of course, this approach wouldn't work as well in Windows, because
> > Microsoft's overuse of alerts and poor alert design would probably
> > result in users blindly clicking 'Yes' every time.)
>
> This problem is not because of the dark aura of Bill Gates. Warning
> dialogs always have this problem; it's a well known UI pitfall.
>
> I do not see that Mac OS X uses alerts any the less than Windows,
> though I admit that Mac OS X button labeling tends to be better.
> Windows makes Yes/No so easy, everyone does it.

OS X does actually seem to have fewer alerts of the 'You don't really
need to know this, but I'm telling you anyway" type.

More importantly, it has better alert design. Not just the better button
labeling, but standard alert layout is to have large, bold text at the
top of the alert which summarizes what the alert is asking in one short
sentence, with a longer explanation below. Windows alerts don't tend to
prioritize information this way (though it's hard to make absolute
statements, since they're pretty inconsistent).

> >> The inability to easily relocate a program is a downside to this, but
> >> given that they hide the contents of Program Files anyway and expose
> >> only installers and uninstallers to the user... it is perhaps not such
> >> a big deal.
> >
> > Uninstallers are, of course, another example of fragile design. They
> > basically assume the system is in exactly the state it was in right
> > after the install, which is not always the case, and they're often
> > fairly ignorant of dependency issues.
>
> This has not been true since about Windows 3.

If this is true, why do uninstallers for major, first-tier applications
still prompt me (in XP) to ask if I want to uninstall 'ALSKDJ.DLL' (or
whatever)?

> (The original API-oriented approach was fragile as you describe, but
> that was a long, long time ago.)
>
> > And the Start menu suffers from similar problems. In fact, the whole
> > reason the Start menu has to exist in the first place is because the
> > file system is so cluttered and so many fragile mechanisms assume that
> > it won't get changed, that it has to be hidden from the user.
>
> Spelunking the file-system for your apps has never been adequate, and
> nobody really thinks it is anymore. That is why Apple opened up the
> Apple menu in System 7, and why NeXT (and Mac OS X) have a dock.

This is clearly not what's going on here. The Apple menu and the Dock
are there for convenience They're locations where the user explicitly
places frequently used apps. This makes them similar to the top level of
the left side of the Start menu in XP, where the user can place
frequently used apps.

The 'All Programs' section of the Start menu (or whatever it's called),
in contrast, lists all apps on the system, and apps appear there without
the user explicitly specifying this. Mac OS (any version) and NeXTStep
have no equivalent of this. Windows *needs* this because C:\Program
Files is an unholy mess which needs to be hidden from users, whereas
/Applications is, you know, not.

> And the original Start Menu was just the Apple menu made more obviously
> a control, and formalized a bit. It was the official answer to "how to
> users find my app after installing it?", replacing the execrable
> ProgMan.exe in the role.
>
> The original Start Menu *was* flawed though. It allowed arbitrary
> programs to insert themselves anywhere. Programs did would then try to
> attract attention by obnoxious placement. The XP Start menu fixes this,
> but is otherwise much the same. It works really quite well.
>
> > Basically, the whole architecture of Windows seems to be designed
> > around the idea that nothing will ever be changed on the system except
> > through 'approved' mechanisms like installers or Wizards.
>
> It is more the idea that nothing *should* be changed except through a
> GUI- such as a wizard or an installer.
>
> Microsoft encourages this strongly, and some elements of the system
> only work if it is true. But they are important things like the COM or
> the service control manager, so it is Very Bad if this turns out to be
> untrue.

It's fragile and hackish. Microsoft took a system that didn't understand
any of this stuff and hacked it all in at high levels, rather than
building it in lower down. It shows.

> > This is exceedingly silly, because there are many other mechanisms
> > that can change things, including user interaction, technical mishaps,
> > and software running on the system
> >
> > It's analogous to designing a journaling file system that only updates
> > the journal when files are updated in *some* ways and not others. I
> > think we can agree that would be bad design, yes?
>
> That what journalling filesystems do. Only updates to file metadata are
> protected; file content is not.

You're being pedantic again. In this analogy, say, copying files in the
file manager would update the journal, while saving files from an app
wouldn't.

That's basically what Microsoft has done here. They've created a system
that requires certain metadata to be in sync with the actual contents of
the file system, and failed to provide a mechanism to make sure that
always happens.

> >>> This kind of static approach to keeping track of things show up in many
> >>> places in Windows, and it's frankly just a sign of lazy design.
> >>
> >> What other places?
> >
> > The whole way Windows handles hardware seems to suffer from some of the
> > same design flaws. We've discussed this before.
>
> I don't seem to recall that.

Basically, the drift is, Windows seems to maintain a sort of semi-static
hardware profile, and when hardware changes certain mechanisms are
supposed to engage to modify this profile.

Windows also seems to have a three-tiered system for drivers. There are
drivers that are on the disk, but not 'installed', there are drivers
that are 'installed' but not loaded (that is, they're part of the
hardware profile, but the devices they work with aren't present), and
then there are drivers that are actively being used.

OS X takes a very different approach to all of this. For starters, there
are only two states for drivers; sitting on the disk unused, and
actively being used. Any time OS X detects a device, it checks on disk
to see if it has a driver, and if it does that driver is loaded
immediately. Moreover, OS X has no static device profile at all; every
time the system boots, everything from the motherboard chipset to the
external USB devices is dynamically detected. (And OS X still manages to
boot much faster than XP....)

> Though I could see a Mac user finding this aspect of Windows
> unpleasant. Windows tends to avoid building intelligence about hardware
> into the OS; it goes into drivers instead and this can be limiting.
> This is essential to Windows goal of supporting pretty much any
> hardware, but it means the experience can't be as completely tailored
> as might be ideal.

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