Re: OSX on Intel Could Destroy Microsoft

In article <mr-EC0EAF.08305328112005@xxxxxxxxxxxxxx>,
Sandman <mr@xxxxxxxxxxx> wrote:

> In article <znu-0E060C.14382427112005@xxxxxxxxxxxxxx>, ZnU <znu@xxxxxxxxxxxx>
> wrote:
>
> > > 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.
> >
> > That's honestly a fairly useless way of setting the time
>
> But *easy*. which is what I was talking about. It should of course be
> accompanied with the controls I described below
>
> > but I suspect it could be done by a sufficiently determined developer,
> > and it might not even be harder than implementing the draggable clock
> > view in Quartz on OS X was.
>
> But I want it to be supported by the web browser, not depending on a
> javascript
> solution.

Again, I guess this is a matter of how see the role of the browser. Is
it more comparable to, for instance, Quartz, or Cocoa? In other words,
should it provide high-level UI controls, or should it just provide the
primitives to build them, and allow the standardization of high-level
controls to happen in e.g. web frameworks like Rails?

> > > Yes, that's nice - but I still need to develop for the lowest common
> > > denominator - IE.
> >
> > That's being a little unfair, isn't it? If we're comparing desktop apps
> > to web apps, it's worth remember that an app that works in just Firefox
> > and Safari still has a wider potential reach than an app that only
> > works on a single operating system.
>
> Not sure what you mean - Outlook on a Windows PC sure has more compatible
> environments than a web app that requires Safari or Firefox.

If you mean not everyone has Firefox or Safari installed, that's true.
But pretty much everyone *can* install Firefox or Safari, if they see a
compelling reason to do so. I've had no problem convincing clients to
install Firefox for accessing back-end interfaces, for instance, which
has allowed me to do things there that would have been much more work if
IE also had to be supported.

[snip]

> > I disagree here. I think commands are more discoverable when they're
> > visible in context than they are if they're all grouped together, for
> > two reasons.
> >
> > One is, when commands are all grouped together, there tend to be a lot
> > of them, and each individual one is to some extent lost in the noise.
> > This is particularly true in large desktop apps.
> >
> > The second reason is, if you've got a list of all the commands, you know
> > what the commands are... but now you need to spend time discovering
> > where they apply! When you add a To-Do item, where does it go? Or in a
> > desktop app, if a command is grayed out, what context do you have to be
> > in for it to become available? In-context commands avoid these problems.
>
> Exactly. But "append to list" is a global command, since it applies
> to "the list" not "a list item". I generally keep context-specific
> actions tied to the specific items, such as "edit" and "delete". The
> reason for this isn't that it's more logical, its because the web UI
> can't "objectify" items naturally.
>
> If I could apply desktop UI standards, I could shift-select several
> items in todo-list and then have a global command that applies to the
> selected items.
>
> But, as I said - "add todo item" is a global command and not a
> context command, even if it actually appends to the list at a
> specific position (mind you, the list may be sorted in a way that the
> new todo might not appear at the end).

It's not specific to the context of an item, but it is specific to the
context of a list. It's more natural, IMO, to click 'Add Item' on a list
than it would be to (to use a common desktop pattern), make a list the
active view and choose 'New Item' from a menu.

And in Basecamp, a newly added to-do item *is* always added to the end
of the list.

> So I solve this with either a hidden layer or a popup. A form not
> found until you've scrolled to the very bottom isn't really good UI
> here, IMO.
>
> In my forum module, however, I keep actions in the spot where posts
> will appear, which I know beforehand depending on whether people are
> looking at it in linear or hierarchical mode. So, in linear mode, the
> new post will appear at the end, so that's where the "add post"
> button is. In hierarchical mode it will appear at the top, so... But,
> this doesn't mean I put the entire form at that spot, just the action
> button.

Well, with Basecamp, the action button expands into the form -- which is
another neat example of maintaining context.

The form stays expanded (unless you close it) after the first item
you've added to make it easier to add other items.

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

Loading