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

Suggestions

From Universal Edit Button

(Difference between revisions)
Jump to: navigation, search
(reorg'ing to move Implemented suggestions to its own page)
(JavaScript links for AJAX-driven edits)
Line 83: Line 83:
Would the existing Firefox plug-in handle this? --[[User:John Abbe|John Abbe]] 05:44, 21 June 2008 (UTC)
Would the existing Firefox plug-in handle this? --[[User:John Abbe|John Abbe]] 05:44, 21 June 2008 (UTC)
 +
:for a javascript url, wouldn't a type be not needed? The type attribute is not required in the html specification, and really the link is referring to the javascript "edit()" function, not a document of the type text/javascript. [[Special:Contributions/24.65.78.101|24.65.78.101]] 05:30, 22 June 2008 (UTC) (user:bawolff elsewhere)
== Show URL when hovering ==
== Show URL when hovering ==

Revision as of 05:30, 22 June 2008

< Community Portal

Contents

Add a suggestion

Also see Implemented 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)

As per my comment below, the edit button should indeed disappear when you're on the edit page. The edit button's presence means "this page is editable". If you're on the edit page, the edit page itself is not editable. The question of whether another button (save, preview, etc) should take its place is another discussion. Personally I think a 'preview' button makes more sense than a 'save' button, but not every wiki will support a preview functionality... Jeff schiller 19:44, 20 June 2008 (UTC)
The regular edit button doesn't disappear (in MediaWiki at least) when you are editing, and for good reason. If you want to scrap your changes and start again from the most recent diff, hitting the edit button again from the edit window is the fastest way of doing so. It's not just laziness leaving it there, it's for a purpose. If the edit button doesn't disappear in regular wiki editing, then it shouldn't for the UEB either. It'd be confusing and cumbersome to experienced wiki editors to have the UEB do something that regular edit buttons don't - the point is to have it be a more visible avenue in to editing as we know it, not to reinvent what happens when you open the edit window. StevenWalling 20:36, 20 June 2008 (UTC)
This is something each developer can decide for themselves, yes?--John Abbe 05:41, 21 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.

This is an error on the wiki author site - the edit page is not itself editable so the link element should not be present there. Once this is fixed, the edit button would go away from the address bar in Firefox automatically. Jeff schiller 19:42, 20 June 2008 (UTC)

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)
      • I think the pencil symbol is just fine - let's not overthink this. My only complaint is that it's a little too small for the icon, it could be enlarged by a couple pixels on either side so it's clearer what it is. The green is distinctive and the gradient is a nice web 2.0-ish touch. By the way, the firfox extension, the 'edit' button in the URL bar is slightly smaller than the feed button - I think they should be equal size. Jeff schiller 19:46, 20 June 2008 (UTC)
        • yeah, I noticed the size difference too. I'd definitely agree it should be equal with the other symbols. StevenWalling 20:42, 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)

In this context "wiki" represents an invitation to collaborate on a lasting work. Confusing wiki with edit is like confusing "celebrating an anniversary" with "eating cake".

So it should be called the "Universal collaborate on lasting work" button?

I was just thinking that when i first read about this. I always thought that rel="alternate" meant an alternate representation of the document (different format like a printable postscript version, different language, etc, but still the same document) to me a link rel="alternate" type="text/x-wiki" ... should go to a version of the page in unphrased wiki code (like http://universaleditbutton.org/index.php?title=Suggestions&action=raw&ctype=text/x-wiki ) if the link goes to a webpage, it should have the type text/html or application/xhtml+xml . rel="edit" would make much more sense in my humble opinion. 24.65.78.101 05:13, 22 June 2008 (UTC) (user:Bawolff on Wikinews/wikipedia/and anywhere else i have an account)

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.

JavaScript links for AJAX-driven edits

If the current page can start the edit process using AJAX, it'd be nice for the UEB link to take advantage of that. We could abuse the href attribute with a javascript: link, but then we'd lose people who browse without JavaScript enabled (and that would feel dirty, anyway).

That being said, I'm not sure how to be implement this. Possibly a second link tag?:

<link rel="edit" type="text/javascript" title="Edit this page!" href="javascript:edit()" />

--Mark 23:02, 20 June 2008 (UTC)

Would the existing Firefox plug-in handle this? --John Abbe 05:44, 21 June 2008 (UTC)

for a javascript url, wouldn't a type be not needed? The type attribute is not required in the html specification, and really the link is referring to the javascript "edit()" function, not a document of the type text/javascript. 24.65.78.101 05:30, 22 June 2008 (UTC) (user:bawolff elsewhere)

Show URL when hovering

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

Firefox toolbar button?

I'd like to promote this icon to a top-level toolbar icon alongside Back/Forward, etc. --Mark 23:02, 20 June 2008 (UTC)

The other icons are not site specific, so it's kind of asking for too much to have the icon there. It would be enough for now to have it native, like the RSS auto-discovery feature. Maybe your idea makes sense for Flock, though?! Ehud Lamm 23:07, 20 June 2008 (UTC)
I'm not sure I agree with that logic -- it has Cut and Paste buttons, after all. :) --Mark 23:43, 20 June 2008 (UTC)
It's not that I don't agree in principle. I just think it is premature (consider safety). Getting it in the location bar natively seems more relevant at the moment. --Ehud Lamm (by the way, I am on a public computer without the extension, and it took me a second to realize where the edit link was on the page... The UEB is addictive!)
sounds awesome though! maybe a rss button too! ~~ MarkDilley

UEB.org's favicon - use the pencil icon!

The universaleditbutton.org favicon should be the same pencil icon, not the logo which is an unrecognizable mess at such a small size... Waldir 10:15, 21 June 2008 (UTC)

Use the icon in the page, too

Perhaps in a second stage, the same wiki platforms that got together to implement this extension could add the icon next to the edit links, just like ward's wiki and aboutus.org do right now (I only know these two cases but I bet there are more). That would help spread knowledge and recognizability of the icon. --Waldir 17:55, 21 June 2008 (UTC)

Key command for editing the page

Now that the browser has a point & click interface for editing, how about a standard key command? Control/Command-E doesn't seem to be in use... --John Abbe 04:38, 22 June 2008 (UTC)

Personal tools