21,998 downloads - November 30, 2015
We have switched to admin only, please email markwdilley@gmail if you would like to edit.


From Universal Edit Button

Revision as of 19:30, 20 June 2008 by StevenWalling (Talk | contribs)
Jump to: navigation, search
< Community Portal


Add a suggestion

Unimplemented suggestions

Universal edit and save button

It would be really nice to have the button be able to save the page too, once you used it to open the edit window. Is the technical capacity to have it link to edit and save too difficult? This suggestion kind of goes along with the one below, except that I disagree that the button should disappear once you've clicked it and opened the edit window. StevenWalling 19:08, 20 June 2008 (UTC)

Edit button changed when on edit page

When the edit page is already opened the button should ideally change to either be disabled (or else the current changes are lost if the user clicks the button again) or changed into 'save changes' button.

Additional Image Ideas

  • One simple idea would be to create an icon that is more representative of an "electronic" or "online" era rather than using the traditional "pencil" icon which represents a "paper" era. A suggestion would be to have an icon showing a few keys on a keyboard with the Enter key (showing the arrow <--) depressed. Color scheme I'm unsure of, but it might be one way of showing the action for "edit" rather than a pencil writing on a page. I realize that the pencil is pretty standard for editing something across many applications and on the Web, but it's just an idea.
    • the logo for this wiki represents about 3/4 the ideas we had during the last 15 months of talking about this idea. We look forward to fresh ideas and designs! :-) MarkDilley
      • I would like to think in a completely opposite direction: a symbol that isn't tied to any anachronistic technology or cultural paradigm, whether it's the analog or the digital. My favorite thought so far is a hand (maybe like the one in this sketch of ideas). A symbol that doesn't have to do with technology, but which simply says that this is a "hands on" website fits the bill for me. Universality is a big goal here in terms of a symbol, and it doesn't get much more universal than a hand... StevenWalling 19:30, 20 June 2008 (UTC)

Rename the Firefox Add-on...

...from wiki auto-discovery button to Universal Edit Button

The rel and/or type should be...

(Right now we're using rel="link" and type="application/x-wiki" - which would become "application/wiki" once we register whatever we settle on. When we're settled, see http://www.iana.org/cgi-bin/mediatypes.pl to begin that process.)

To fit better with the defined purpose of the link tag and its attributes, I think a better way to format the edit link would be like this:

<link rel="edit" type="text/html" title="Edit this page!" href="wiki?edit=WelcomeVisitors"/>

The content-type of the response is text/html typically, and the relationship of the link to the current page is that you're going to edit it. --Mryall 23:57, 19 June 2008 (UTC)

I'm wondering about application/x-wiki & application/wiki, on two levels. One is again reluctance to label this as being inherently wiki-related.

The other has more to do with what type is supposed to specify in the first place. From looking through the RFCs, it sounds like type is intended to describe the data being returned, rather than a function. If that's true, i imagine it would have to be able to be different for different systems. An edit page might HTML here (text/html), XHTML there (application/xhtml+xml), or not even a web page, but data that gets dynamically used to offer the ability to edit (e.g. in Wagn; not sure what type of data it is).

If the spec is ok with the label describing the function, then what about application/edit? --John Abbe

There's always crazy possibilities like "text/html; content-disposition=edit" ... --Brion Vibber

  • I second the notion of rel="edit". I also disagree with the notion that wikis need a separate MIME type. Blogs don't. Forums don't. I consider the MIME type as the format (HTML, SVG, Atom). See here for elaboration. Jeff schiller 18:47, 20 June 2008 (UTC)

Menu when more than one editable item on the page

Or some way to handle websites (e.g. MediaWiki, Wagn) that have more than one editable item per page.

Add multiple <link...> tags of whatever format we end up with. Then if the browser finds more than one, a menu of those editable items appears when they click on the edit button (a title= key/value pair in the code determines what appears in the menu for each item. --John Abbe 06:17, 20 June 2008 (UTC)

I thought about this before the release today, and I am not sure if this the best option. It is of course the natural way to do it, but it may be too confusing, at least until people get used to the idea of an address bar button. I think it may be best to link to the most reasonable default choice (e.g., in WP the edit link of the page, not of the sections). If no such thing exists it may be best for sites to point to a page the explains the situation, and then offers the relevant links. Ehud Lamm 06:29, 20 June 2008 (UTC)

Could be a preference in the add-on.--John Abbe 06:36, 20 June 2008 (UTC)

The button could also show a pop-up menu (like the RSS one or Bookmarks one does) to allow selection of a particular section of the article to be edited. --Anonymous

Non-REST interfaces

Handle websites that don't use a plain URL to trigger editing.

Show URL when hovering

When your cursor's hovering over the edit button, have the status bar show the URL.

Implemented suggestions

Tooltip should be more explicit

(Implemented in the spec anyway; websites can each do whatever they like of course.)

I know this may seem really, really minor, but look at the tooltips for the address bar icons in Firefox 3:

  • RSS icon: "Subscribe to this page..."
  • Bookmark (star) icon: "Bookmark this page"
  • Universal Edit icon: "Edit"

For the sake of consistency and clarity, that last should probably be "Edit this page..."

Part of the reason for this is that people are not used to being able to edit pages directly. "Edit" could mean something else -- maybe "Edit URL". Be unambiguous.

Why not use the value of the title-attribute as tooltip? Like that, sites could determine individually what they offer and explain details like "If you were logged-in, you could edit this page" or "Registered users can edit this page..." or whatever to encourage visitors to overcome whatever prevents them from actually editing the page.

Personal tools