Microformats in Firefox 3 - looking for naming suggestions
Michael Kaply
trying to figure out is how to name this stuff. You are going to have
the ability to add new functionality to the microformats layer, similar
to how the Options->Feeds works today.
Would we consider these to be feed handlers? or feed actions?
I'm just wondering what we'll call them in the microformat world. Is
handlers too nerdy?
Or is there some other good word to describe this functionality?
To give an example:
For hCard, out of the box you'll be able to export it to Outlook, but
adding it to Yahoo Contacts might be a separate thing that you download
and install so now you can add it to outlook or to yahoo calendar.
Thanks for any input.
Mike Kaply
Asa Dotzler
In UI, we say something simple like:
subscribe to this feed using [________v]
so wouldn't you do something similar for microformats? How about
something like:
add this calendar item to [________v]
- A
Alex Faaborg
sure we should do. I'm cc'ing Shaver since I hear he is great at
naming stuff.
We need a user facing name for microformat handlers, which (like
extensions, plug-ins and themes) you can add to Firefox.
Since the only way to interact with microformatted content in Firefox
3 will be through context menus, cued by changes to the mouse cursor,
perhaps we should call the various handlers "pointers." For instance
consider this conversation:
User A: "Hey, when you move your mouse over the times on the schedule
your mouse pointer had the 30 boxes icon, how can I do that?"
User B: "you need to get the 30 boxes pointer."
[User B searches for "30 boxes pointer" and installs the pointer]
One big downside of this naming approach is that it ties us to a
particular UI. However, having close ties between the name and the
UI makes it easier for people to discuss features they like:
User C: "You've got to check out this new feature in Firefox 3, when
you move your mouse over stuff, Firefox can send it to your favorite
application. All you have to do is download pointers for all of the
applications you like to use."
User D: "Firefox 3 includes several new features, like private
browsing, malware detection, the ability to tag bookmarks, and
pointers."
Another downside of this name is that collides with a lot of
technical topics (referencing memory, XPointer, etc.) Also, the name
isn't even accurate: while "mouse pointer" is a more popular term, it
really should be called the "mouse cursor."
Anyone else have ideas,
-Alex
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
Clint Talbert
..snip..
> We need a user facing name for microformat handlers, which (like
> extensions, plug-ins and themes) you can add to Firefox.
>
> Since the only way to interact with microformatted content in Firefox 3
> will be through context menus, cued by changes to the mouse cursor,
> perhaps we should call the various handlers "pointers." For instance
> consider this conversation:
>
the risk of sounding like the standard C++ vs. Java argument, I think
you could also use the word "reference". "Reference" is slightly less
technical, and indicates what these things are: References Firefox can
use to import data into your favorite application.
After thinking about how much I hated the word "reference", I thought up
the idea of calling it a "hint" or a "clue". User B could explain the
functionality like this: "It gives Firefox a hint/clue about how to
handle this link."
So, maybe that will spur some discussion and folks can think up better
names than these :-)
Clint
Deb Richardson
If you've ever played a poorly-designed graphical "adventure"-style game (like Myst), you'll understand how frustrating it can be to _suspect_ that there's some interactive material on a screen but you can't find it to save your life. The end result is that you end up sweeping your cursor across the screen over and over and over again trying to find the one small spot where the cursor changes from a pointer to a hand, which is the _only_ indication that a particular area is interactive.
Is there any other/additional way we could notify users of the existence of microformat content on the page and, ideally, allow them to interact with it without having to hunt through the entire page contents to find it first?
~ deb
Alex Faaborg
> microformat content in a page?
That is currently the plan, although I would also like a chrome-based
UI.
> If you've ever played a poorly-designed graphical "adventure"-style
> game
Having played nearly every graphical adventure game released between
1984 and 1999, I certainly get your analogy :)
> Is there any other/additional way we could notify users of the
> existence of microformat content on the page and, ideally, allow
> them to interact with it without having to hunt through the entire
> page contents to find it first?
I really want microformat detection added somewhere to our chrome,
but beltzner and mconnor don't seem as interested. Here is a rather
comprehensive list of possibilities: http://wiki.mozilla.org/
Microformats/UE/ideas
-Alex
Mike Beltzner
> I'm just throwing this out as an idea, not necessarily something I'm
> sure we should do. I'm cc'ing Shaver since I hear he is great at
> naming stuff.
Yeah, he and I talked a little bit about this, and he mentioned that
he had some ideas that he wanted to tack onto this thread. Perhaps
talking about him in the abstract will spur him to action there.
(One might ask why I don't just point my recollections, and the simple
truth of the matter is, I don't actually recollect!)
> We need a user facing name for microformat handlers, which (like
> extensions, plug-ins and themes) you can add to Firefox.
As a point of order, I don't like committing ourselves to "branding"
before beta (though I don't think that's what you're asking for here)
since I'd like to think we'll be nimble and reactive enough to
feedback from beta to be able to change the UI of a feature, or the
name, or whateever. So I don't think this is mega-urgent, but it is an
interesting conversation to have.
I think the better way to present these are as different types of
content handlers, where the content type could be hCal, hCard, vCard,
JPG, href, etc, etc. The interaction here is "take this object with
its data and metadata and put it over here". Back in early Windows
days, people called this "Send to", though that name tended to cause
more confusion than good.
> Since the only way to interact with microformatted content in Firefox
> 3 will be through context menus, cued by changes to the mouse cursor,
> perhaps we should call the various handlers "pointers." For instance
> consider this conversation:
Like you point out, that ties us to a user interface paradigm that we
might not stick with in the short or long term.
I find the functionality to be pretty analogous to Yahoo Pipes, which
was probably named as a slightly-geeky reference to the | operator,
but also as a way of bringing up the concept of dataflows and routing.
Along those lines, and with due deference from the Honorable Senator
from Alaska, one might be tempted to call our things "tubes".
cheers,
mike
Mike Beltzner
> Would "Pointers" be the only way to discover and interact with microformat content in a page?
By default, yes. In almost all the primary use-cases for microformats,
the user is expressing interest in delving deeper into the descriptive
metadata of some element, be it an address, event, geotag, etc. That
data wasn't explicitly rendered for a reason, presumably, either that
it wasn't relevant to the majority of users, or that until someone
wanted to act on it, there was no need to show all the detail.
The idea of the UI we're moving towards is to intercept user actions
on the elements and then indicate "hey, there's richer data here that
I can do clever things with."
As Alex indicated, we've looked at several other options, but they all
seemed too "in the user's face" for cases where they simply weren't
interested in that event, or person, or geotag, or whatever, which we
quickly realized (through use of Operator) was a far more frequent
happenstance.
> If you've ever played a poorly-designed graphical "adventure"-style game (like Myst), you'll understand how frustrating it can be to _suspect_ that there's some interactive material on a screen but you can't find it to save your life. The end result is that you end up sweeping your cursor across the screen over and over and over again trying to find the one small spot where the cursor changes from a pointer to a hand, which is the _only_ indication that a particular area is interactive.
Yeah, that's one reason why my previously-preferred UI presentation
was to act like hyperlinks, decorating the element on the page subtly
yet consistently. Because this metadata is often attached to block
elements, though, that ends up looking pretty strange in a lot of
cases, with outlines around huge sections of the page.
> Is there any other/additional way we could notify users of the existence of microformat content on the page and, ideally, allow them to interact with it without having to hunt through the entire page contents to find it first?
Sure. Toolbars, indicators like the RSS indicator in the location bar,
outlines. Operator has gone through several of these iterations, and
users found each to be equally frustrating:
- toolbars were modal, and took up a lot of space
- indicators (in location bar and status bar) worked well, but for
pages with a lot of metadata-enriched elements, navigating through the
lists to find the thing you were interested in was frustrating,
especially when in most cases it was right there on the page in front
of you
- outlines and on-hover treatments were a little confusing, and
didn't play well with metadata-enriched block elements
One thought I recently had was whether or not we might just want to
switch the UI treatment so that the elements get the finger-icon when
hovered over, and we display UI to act on the information when the
user *left* clicks. That way web authors can tell users to click, or
render the elements like hyperlinks, or make the elements look like
buttons, and then we can intercept the click and take an action. That
has problems, too, but ends up getting away from the swipe-to-discover
problem.
cheers,
mike
Robert Sayre
>
> The idea of the UI we're moving towards is to intercept user actions
> on the elements and then indicate "hey, there's richer data here that
> I can do clever things with."
>
> As Alex indicated, we've looked at several other options, but they all
> seemed too "in the user's face" for cases where they simply weren't
> interested in that event, or person, or geotag, or whatever, which we
> quickly realized (through use of Operator) was a far more frequent
> happenstance.
Microformats are cool and everything, but they are still pretty
unproven. I am pleased that we are working on detecting them in a
performant and accurate manner, so that extensions can do interesting
things with them. I don't feel that any built-in UI should block Firefox 3.
-Rob
Deb Richardson
----- "Robert Sayre" <say...@gmail.com> wrote:
> Microformats are cool and everything, but they are still pretty
> unproven. I am pleased that we are working on detecting them in a
> performant and accurate manner, so that extensions can do interesting
> things with them. I don't feel that any built-in UI should block
> Firefox 3.
Yeah, I'm not sure how high a priority I should be putting on this
discussion, to be honest. Obviously I have some concerns about Pointers
being the sole method for discovering and interacting with Microformats,
but clearly I'm missing some context and background regarding the
work that has already been done here.
Is there documentation I could read to get more up to speed? I'm
primarily interested in the Use Cases we're hoping to address and
results from experiments and UI that have already been tried and
discarded as possibilities.
I did dig around a bit but couldn't find this specific information.
~ deb
Mike Shaver
> On May 21, 7:22 pm, Alex Faaborg <faab...@mozilla.com> wrote:
> > I'm just throwing this out as an idea, not necessarily something I'm
> > sure we should do. I'm cc'ing Shaver since I hear he is great at
> > naming stuff.
>
> Yeah, he and I talked a little bit about this, and he mentioned that
> he had some ideas that he wanted to tack onto this thread. Perhaps
> talking about him in the abstract will spur him to action there.
Public shaming is a crude, though apparently effective, tool for
manipulating my schedule, Mr. Beltzner. You should be ashamed of
yourself, or something.
My thoughts:
- "pointer" is an icky name, for all the reasons that you mention,
plus the fact that I don't think it actually describes the
user-relevant characteristic. The user doesn't care that it "points"
to some other service, the user cares what happens to their data.
- given the presence of content-handling systems for helper apps and
plugins and such, I don't think we should have separate UI or, where
possible, mental models for content that we extract from microformats
or RDFa, vs. that from clicked links or bits of media pulled from RSS.
The *least* important aspect of a datum we're processing is whether
it came from microformat markup or an attachment in my webmail.
- so I think that we should have "handlers", which also gives a
serviceable if somewhat overbroad verb "handle" for prosaic use, and
we should dispatch content through those same mechanisms in as unified
a manner as possible
- thus, clicking an ICS attachment or interactifying with an hCalendar
element (or RDFa equivalent, or custom-scraped greasemonkeyalike thing
so that I can get useful calendaring stuff out of expedia, thank you
brother) should go through the same paths. As should being invoked as
the system handler for text/ics or .ics files, if we're thusly
registered in the brave future of Fused system content-handler support
- where we can use MIME types for distinguishing which handlers are
relevant, I believe that to be the virtuous course, but there will be
cases in which we can't. I believe that there are, for example, no
MIME types (let alone IANA-registered ones, hoo boy) for saying 'this
is a photograph', but we might want to distinguish 'photo that I might
send to flickr' from 'banner image on web site' for determining when
to present whichever cues we choose. I think that leaves us needing
to synthesize some MIME types, as was done when <applet> grew up into
a type of <object>. (In the specific photograph case, we could likely
detect pretty well through the presence of EXIF, and get an awful lot
of such cases for free. I believe that luser has EXIF-manipulation
code in JS somewhere, in fact.)
- there's a tie-in to page info here somewhere as well, but I can't
articulate it, so Beltzner will have to shame me again at some point
in the future.
Mike
Jesper Kristensen
Do we need a name?
When the user sees a contact microformat, he can right click on it and click
"Use Contact" or something like that. Then Firefox could generate a vCard
from the hCard and do whatever Firefox is configured to do when seeing a
vCard. No need for extra configuration here. I don't know if similar file
types or URI schemes exist for locations and events. If not, we could make them.
If users would like to add detection for new microformats, they would do that
by installing extensions. I do not see a need for distinguishing between
microformat extensions and other extensions.
If we allow users to turn microformat detection on and off completely, we
would need a checkbox for that. But here we are not limited to a short name.
We could use a short sentence that describes the feature.
Sailfish
>> Would "Pointers" be the only way to discover and interact with
>> microformat content in a page?
>
>
>> If you've ever played a poorly-designed graphical "adventure"-style game
>
> Having played nearly every graphical adventure game released between
> 1984 and 1999, I certainly get your analogy :)
>
may be problematic for large content areas, though?
--
Sailfish - Netscape/Mozilla Champion
Netscape/Mozilla Tips: http://www.ufaq.org/ , http://ilias.ca/
mozilla-based Themes: http://www.projectit.com/freestuff.html
Jesper Kristensen
> Maybe a semi-opaque dotted outline on the page microformat content? This
> may be problematic for large content areas, though?
I think it should be the website's responsibility to indicate that you can
interact with the element.
Mike Connor
Agreed 100%. I don't think you can get a one-size-fits-all
presentation anyway.
-- Mike
Mike Connor
On 25-May-07, at 6:49 AM, Jesper Kristensen wrote:
> Michael Kaply skrev:
>> In working on Microformats in Firefox 3, one of the things that I'm
>> trying to figure out is how to name this stuff. You are going to have
>> the ability to add new functionality to the microformats layer,
>> similar
>> to how the Options->Feeds works today.
>>
>> Would we consider these to be feed handlers? or feed actions?
>>
>> I'm just wondering what we'll call them in the microformat world. Is
>> handlers too nerdy?
>>
>> Or is there some other good word to describe this functionality?
>>
>> To give an example:
>>
>> For hCard, out of the box you'll be able to export it to Outlook, but
>> adding it to Yahoo Contacts might be a separate thing that you
>> download
>> and install so now you can add it to outlook or to yahoo calendar.
>>
>> Thanks for any input.
>>
>> Mike Kaply
>
>
> Do we need a name?
IMO, no. Branding features, especially ones that are unproven and
limited-adoption-at-present, is a mistake.
> When the user sees a contact microformat, he can right click on it
> and click
> "Use Contact" or something like that. Then Firefox could generate a
> vCard
> from the hCard and do whatever Firefox is configured to do when
> seeing a
> vCard. No need for extra configuration here.
Agreed, again (I sense a trend).
-- Mike
Impro Fane
a menu is always at the top or at the left, maybe people could find
the hidden content easier?
Perhaps a semi-permanent sidebar that displays detected microformats
in a similar fashion to how MTAs display different types of email. It
would be categorized with headers and expanded by default. It would
probably be suited best on the right since the left would be confusion
and offset the page too much.
Right clicking on an item would be the equivalent of right clicking it
as it is on the page. An alternative action would be to move the page
to the position where the microformat is embedded.
Impro Fane
When you install a new microformat, you are adding the ability to
access new data. This is analogous to the television - because you
must tune your television to receive different channels. I think
pointer is too synomous with links. When we extract data from
microformats, we are channeling data rather than pointing or linking
to it. You could treat the available data as the individual slots of
the channel.
I suppose you "subscribe to a channel" rather than "install" it. You
are opting in to receive the channel?
Mike Shaver
>
> On 25-May-07, at 7:44 AM, Jesper Kristensen wrote:
> > you can
> > interact with the element.
>
> presentation anyway.
Disagree with the premise -- we have a standard way of indicating the
presence of RSS content, which I think works pretty well, and I don't
know why we wouldn't be able to do something in a similar vein for
embedded metadata like microformats.
Also: the web site likely doesn't know if the client that the user is
using will let them interact with the element. How should a site
determine that a given user -- even a given Firefox user, should we go
down that ugly sniffing path -- has a parser install for hBugzilla or
hHockeySpoiler so as to indicate that the element is responsive?
Mike
Alex Faaborg
with. The third reason I believe the browser should handle
microformat detection is the chicken and the egg problem: if Firefox
supports microformat detection, then Web sites will have a motivation
to provide this streamlined functionality for their users. If we
require the site to do additional UI design, we really increase the
barrier to entry. Plus, a lot of wikis and blogs will strip out
javascript, but they won't remove the additional attributes needed to
add semantic information to content.
>> I don't think you can get a one-size-fits-all presentation anyway.
I completely agree. I think Web sites should still be able to
override a cursor change and provide their own UI (links, buttons,
etc). I also think we should release some creative commons vector-
based art files for the various icons we think each data type should
have, similar to how the RSS icon now appears across the Web in a
variety of shapes and colors, but with the same iconic and
recognizable form.
However, if the site doesn't specify their own UI, I think we should
provide a default interface for interacting with microformatted
content that is based on augmenting the cursor, right click context
menus, and the unified content handling dialog.
-Alex
On Jun 3, 2007, at 7:34 AM, Mike Shaver wrote:
> On 6/1/07, Mike Connor <mco...@mozilla.com> wrote:
>>
>> On 25-May-07, at 7:44 AM, Jesper Kristensen wrote:
>>> I think it should be the website's responsibility to indicate that
>>> you can
>>> interact with the element.
>>
>> Agreed 100%. I don't think you can get a one-size-fits-all
>> presentation anyway.
>
> Disagree with the premise -- we have a standard way of indicating the
> presence of RSS content, which I think works pretty well, and I don't
> know why we wouldn't be able to do something in a similar vein for
> embedded metadata like microformats.
>
> Also: the web site likely doesn't know if the client that the user is
> using will let them interact with the element. How should a site
> determine that a given user -- even a given Firefox user, should we go
> down that ugly sniffing path -- has a parser install for hBugzilla or
> hHockeySpoiler so as to indicate that the element is responsive?
>
> Mike
Jesper Kristensen
> Also: the web site likely doesn't know if the client that the user is
> using will let them interact with the element.
I think there is a CSS pseudo class for this.