Re: [whatwg] Web Apps 1.0: On-line help
On Mon, 9 May 2005, Dean Edwards wrote: > > > > Unless someone can come up with a way to make discoverability > > practical and usable, there is no point us having [help]. > > It is not all about user agents. I once had to build a web application > with extensive context sensitive help. The app even recalled common > entries for data fields. To make it work we invented an attribute called > "helpID". If the "help" attribute were defined we would have used that > instead. I don't see anything wrong with a Web application using custom attributes (preferably clearly prefixed or in a custom namespace) to store information like this. But I don't see the value in making the attribute for such a case standard. It would restrict what you could do with it, for one -- say the Web app wanted to store just a number for the help. Or just a URI. Or two URIs. Or an IDREF. Or a string. If we had an attribute, we'd have to define what it was, thus either blocking innovation, or using up an attribute for no good reason. > [...reasons why the things I listed might work sometimes...] Yes, all the things I listed are plausible solutions, that's why I listed them. But they're not good _enough_, IMHO. > I think that a help attribute is useful in the realm of web > applications. Applications tend to be more complex than web documents. A > good application is sometimes only as good as its help system. Even if > UAs make nothing of it, web developers would have a standard attribute > to hook their own help systems from. I don't see the advantage of having a standard way of doing something non-standard. It wouldn't improve interoperability. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Apps 1.0: On-line help
Jim Ley wrote: adding in a link rel of help would seem a pretty low rent thing to define, There's already a "help" relationship defined in HTML 4 [1], it doesn't need to be added. Perhaps it's semantics could be refined and maybe give some examples of use and describe some possible implementation methods. [1] http://www.w3.org/TR/html401/types.html#h-6.12 -- Lachlan Hunt http://lachy.id.au/ http://GetFirefox.com/ Rediscover the Web http://GetThunderbird.com/ Reclaim your Inbox
Re: [whatwg] Web Apps 1.0: On-line help
Ian Hickson wrote:
> On Mon, 9 May 2005, Ben Meadowcroft wrote:
>
>> Discoverability would be left to the user agents.
>
>
> Unless someone can come up with a way to make discoverability
> practical and usable, there is no point us having this feature.
It is not all about user agents. I once had to build a web application
with extensive context sensitive help. The app even recalled common
entries for data fields. To make it work we invented an attribute called
"helpID". If the "help" attribute were defined we would have used that
instead.
> Context-sensitive help is well established in modern GUIs, yes. But
> the mechanisms by which it is made available are not available or
> discoverable to the end user in a Web scenario.
>
> For example:
>
> * A cursor doesn't help, since it requires the user to hover over the
> element in order to discover there is help needed.
>
This provides some feedback at least. But Windows apps don't tend to
provide this form of feedback anyway.
> * A hot key is not useful since there is no way for the user to know
> when it would work (and since in the overwhelming majority of cases
> it would do nothing, there is no reason for the user to think to try
> it).
>
An application is something that might be used often. People can
discover F1 for themselves. The UA could at least let the user know that
help is available by enabling the "help" point and click icon.
> * A menu item has the same problem as a hot key.
>
The help menu could be updated with page specific help items.
> * An icon that appears next to controls with help is unworkable since
> the icons would interfere with the page layout and thus need to be
> stylable to satisfy authors. (Furthermore, such help is already
> possible in a backwards-compatible way simply using hyperlinks.)
>
A web developer might want to indicate that help is available though:
[help]::after {
content: url(help-icon.png);
}
I think that a help attribute is useful in the realm of web
applications. Applications tend to be more complex than web documents. A
good application is sometimes only as good as its help system. Even if
UAs make nothing of it, web developers would have a standard attribute
to hook their own help systems from.
-dean
RE: [whatwg] Web Apps 1.0: On-line help
On Mon, 9 May 2005, Ben Meadowcroft wrote: > > Discoverability would be left to the user agents. Unless someone can come up with a way to make discoverability practical and usable, there is no point us having this feature. The user agent manufacturers have already looked at this for some time and failed to come up with any reasonable mechanisms, which is why we removed help="" from Web Forms 2. Saying it is "left up to the UAs" doesn't help us when we _are_ the UAs. :-) > This kind of help is fairly well established in windows, just look at > the internet options dialog of Internet Explorer for an example. Context-sensitive help is well established in modern GUIs, yes. But the mechanisms by which it is made available are not available or discoverable to the end user in a Web scenario. For example: * A cursor doesn't help, since it requires the user to hover over the element in order to discover there is help needed. * A hot key is not useful since there is no way for the user to know when it would work (and since in the overwhelming majority of cases it would do nothing, there is no reason for the user to think to try it). * A menu item has the same problem as a hot key. * A button that can be pressed like in Windows dialogs is not an option because such a button doesn't exist and UA vendors object to introducing new buttons due to the noticable effect it has on usability (based on studies that have been made). * An icon that appears next to controls with help is unworkable since the icons would interfere with the page layout and thus need to be stylable to satisfy authors. (Furthermore, such help is already possible in a backwards-compatible way simply using hyperlinks.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [whatwg] Web Apps 1.0: On-line help
> On 5/8/05, Ian Hickson <[EMAIL PROTECTED]> wrote: > > On Sun, 8 May 2005, Ben Meadowcroft wrote: > > > > > > There are two types of help that I think are appropriate for web > > > applications, full page help and element sensitive help. > > > > The problem with both is discoverability. Unless we can solve that, > > there is not much point having anything in the spec. > > For the context sensitive one we use CSS with a cursor:help > that's the way we usually implement it from a visible > perspective, I'm not sure if there's particular value in > defining an attribute to take the help contents though, > especially as this would mean it couldn't then have mark-up, > which most of the context help systems I've done do use. Having mark-up would be useful. My intent was to provide a method of showing context sensitive help which allowed for a bit more information than displaying the title as a tool tip does. Mark-up would go well with that idea. Discoverability would be left to the user agents. This kind of help is fairly well established in windows, just look at the internet options dialog of Internet Explorer for an example. smime.p7s Description: S/MIME cryptographic signature
Re: [whatwg] Web Apps 1.0: On-line help
On 5/8/05, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Sun, 8 May 2005, Ben Meadowcroft wrote: > > > > There are two types of help that I think are appropriate for web > > applications, full page help and element sensitive help. > > The problem with both is discoverability. Unless we can solve that, there > is not much point having anything in the spec. For the context sensitive one we use CSS with a cursor:help that's the way we usually implement it from a visible perspective, I'm not sure if there's particular value in defining an attribute to take the help contents though, especially as this would mean it couldn't then have mark-up, which most of the context help systems I've done do use. adding in a link rel of help would seem a pretty low rent thing to define, how that may be exposed in a UI though I'm less clear, I don't like the idea of adding it to the browsers regular help chrome - there needs to be a distinction between browser and web-application. Jim.
Re: [whatwg] Web Apps 1.0: On-line help
On Sun, 8 May 2005, Ben Meadowcroft wrote: > > There are two types of help that I think are appropriate for web > applications, full page help and element sensitive help. The problem with both is discoverability. Unless we can solve that, there is not much point having anything in the spec. For example, WF2 used to have a help="" attribute on form controls. We removed it after we got feedback that users would have no way of knowing that there was help available and that it would thus be mostly useless. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Web Apps 1.0: On-line help
I think the web apps 1.0 specification is lacking a section on on-line help. This is a topic which I feel the current work could helpfully handle. There are two types of help that I think are appropriate for web applications, full page help and element sensitive help. I'd suggest first that we standardise a method of linking an application page to it's help page. This could be done by specifying a link relation type specifically for online help. For example: The user agent could then allow users to access the on-line help using the browser UI, i.e. from the help menu where the application specific help could be made available or by pressing the F1 key. My second proposal is to standardise element context help. This will allow a user to get context sensitive help on a particular area of the web page when mousing over or clicking parts of the page (depending on how the OS implements similar features I suppose). This could be enabled by allowing elements to have a context-help attribute (similar to the context-menu attribute proposed). -- Ben Meadowcroft http://www.benmeadowcroft.com/ smime.p7s Description: S/MIME cryptographic signature
