Convener:
Notetaker:
Participants:
Notes
Please include a summary of the discussion, any recommendations or requests that the group had, and any resources the group noted regarding the topic.
What is it?
The Universal Edit Button is a very cool concept that all present hoped would be widely adopted. More information can be found here: http://universaleditbutton.org/ but in short, imagine a button, almost the same as the existing RSS button, that shows up automatically in your browser every time the web page you are looking at is publicly editable. This would apply to all wikis, but also to any other openly editable web pages, with Calagator being a great example (a calendar of events built in Ruby on Rails) but could also be used from blogs (comments) open CMS pages, etc. Currently Universal Edit Button exists as a Firefox plugin and developers are working on a similar plugin for Opera.
Real sample story.
[Steven Walling] was looking at Calagator. As a wiki user he knew all about editing wikis, but he was surprised to see the universal edit button pup up in his browser. This told him Calagator was openly editable. It served as an invitation and a welcome and got him excited about their project.
What are the next steps to develop?
- The button will not be limited only to wikis but should apply to blog software, Content Management Systems (CMS) or any editable page.
- Because most CMS like Drupal, Joomla and Plone, and also complex wikis like WAGN, can have a choice of multiple entities on a single page that can be edited, the option to show a selection list of all possible edits should be shown. This needs some more thought and discussion with the developers. Possibilities to be considered are a top 10 list of what on the page can be edited.
- There is some discussion on whether the button should always show up on an editable page, even if the current user does not have access to change the page. General consensus was that the choice will be with the site developer, but it was agreed that it was desirable to show the button whenever possible. One current approach is to show the button and then display an error message if the user does not have edit authority/is not logged in. However, [Grant Kruger] suggested that the web already has a convention for this and probably a more conventional approach is desirable. Generally on the web a button will be grayed out if a user is not allowed/not yet allowed to click it and a similar approach was deemed desirable. The plugin should also allow for a grayed out button. The site developer can then check their own permissions and make one of three choices, no button, a grayed-out inactive button and a fully active button. This will allow those sites who want a user to know the page is editable, but who require, for example, a login, to show the button as inactive until the user logs in.
- Just as with the RSS button, the button we use will also get used in actual web pages as an edit button. For this reason we need a variety of button color selections.
How do we promote it?
- First, for clarity we need to state up front that the use of the button is desirable, but optional. Additionally, the button should not apply to single user content, e.g. adding a blog entry, but only to content open to multiple people.
- We need to reach out to Firefox and get them to add the button to the browser automatically, rather than merely having it as an optional Firefox plugin. There is a strong Firefox team right here in Oregon and they are active in the local open source communities. We should reach out to them and if we can convince them they will be great champions for the concept. We also need to consider reaching out to other browsers. A universal button requires a universal approach. If the button starts appearing automatically it will bring an immense amount of weight to the concept as we believe it will sell itself once discovered.
- We need to reach out to popular wikis, as well as those who make their wiki software. If we can convince them to interact with the button and also to promote its use, then the concept could spread fairly quickly. Do do this we need to evangelize the strength of a universal approach to content maintenance, the idealism of an interactive and welcoming broader web community and the benefits of an approach that goes beyond just wikis. Reaching out to other communities is also advisable, e.g. Drupal, Wordpress, Joomla, Plone, etc.
Tags
Short description
Remember to link to this session from the Session notes.
