I have been musing about editing pages. Below are the use-cases that I have
come up with for some *simple* tasks, linked to the draft manual that I am
writing. Please drop me a line if I have not covered a common use-case. I will
take silence as adoration, bordering on worship; nothing to do with the time of
year ☺
In summary, the system will be a bit like a wiki and a bit like a blog. On each
page there will be a row of tabs running along just under the main-menu:
Change History Files Add
Like a wiki the page will be version-controlled. However, like a (Wordpress)
blog there is a difference between a document that is published, and one that
is not. Publishing particular versions increases the complexity. However, I
*hope* that this rough draft shows how the simple tasks are simple, but the
complex tasks are possible.
*Simple* *Use* *Cases* (no files or editing of page metadata)
Jane Edits a Page
Jane needs to edit a page to add a link to a report. She navigates to
the page and goes into edit mode. She adds a link to the page, saves
it and checks that it looks correct. Once it is checked she publishes
the change.
* Change the Contents of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-a-page
Miriam Asks for a Change
Miriam asks Nichelle to change to page. Nichelle makes the requested
change and sends Miriam a link to the preview page. Miriam views the
page and sees that it is a draft. After reviewing the changes she
tells Nichelle that the changes look good. After receiving the
all-clear Nichelle publishes the page.
* Change the Contents of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-a-page
* Publish a Version of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-publish-a-version
Lisa Organises a Party
Lisa is organising a Christmas party. As people respond to the email
invitations Lisa updates the page that lists who is attending and
who is not. On Wednesday she notices that Jane also edited the page,
adding extra details about who is joining.
* Change the Contents of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-a-page
Kate has a Question
Kate has a question about something that is written on a page. She
views the history and sees that Lisa last modified the page. She
contacts her, asking her question.
* View a Version of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-view-a-version
Lisa Notices a Mistake
Lisa notices a mistake on a page. She visits the history for the page
and notices that Kate was the last person to edit the page, and that
it was Kate's edit that contained the mistake. Lisa corrects the
mistake, and emails Kate to tell her of the correction.
* Change the Contents of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-a-page
* Compare Versions of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-compare-versions
Lisa Helps a Group Member
A member of a group that Lisa administers is having difficulty seeing
a page — despite being logged in. Lisa checks the page and sees that
it is shown to logged in group members. Lisa double checks the group
member's story, and discovers that the term “log in” was causing
confusion.
* Change the Contents of a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-a-page
*File* *Use* *Cases* (Still no metadata-editing, sorry.)
Nichelle Updates a Picture
Nichelle receives a picture of a hut that has just been repaired. She
adds the picture to the system and sets the system to show the new
image.
* Add Files to a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-files-add-files-to-a-page
Jane Adds a File
Jane updates a page and an associated file. However, but she does not
want either available, so she does not publish them. Instead she
links from the new version of the page to a specific version of the
file. Jane publishes both the file and the page when she receives
approval from Lisa.
* Add Files to a Page
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-files-add-files-to-a-page
* Publish a Version of a File
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-files-publish-files
Very nice progress, Michael!
> On each page there will be a row of tabs running along just under the
main-menu:
> Change History Files Add
The use of tabs constrains horizontal space which, I presume, is why you
have chosen to break with our convention of using the page title as the
link text. In addition, tabs are not currently used anywhere else in
GroupServer. Have you considered somehow using the side menu for this,
perhaps using the navigation device that we use for group-level
navigation? In the following example, "Change" is the default.
Change: Boxers
View History
Manage Files
Add a Page
Animals
Cats
Dogs
Boxers
Poodles
Fish
Your use cases seem good to me. Below are a couple of edits to the manual.
I am concerned about the complexity of the files interface. As you point
out, the handling of page versions adds plenty of complexity by itself.
Handling file versions and permissions separately to the page versions
and permissions means that the user must manage both of these _and_ keep
the two synchronised. To me that's way too hard.
Would it be possible to have a file's permissions inherited from the
page (with the least restrictive permission) that it is linked from?
If a file has no links to it from any page, or
only has links from hidden pages, it is hidden.
If a file has has links from pages that
are not hidden, but has no links to it from
published pages, then the file is not hidden
but not published.
If a file has a link from a published
page, it is published.
Dan
. . .
Manual Edits
http://groupserver.org/groups/development/manage-pages-manual/
* Change the Contents of a Page
In Step 2, "Only people with the correct permissions will not see the
Change link" should be "Only people with the correct permissions will
see the Change link".
* Publish a Version of a Page
Step 1 "Navigate the page you want to change." should be "Navigate to
the page you want to change."
Step 2 "The Change page will be show the most recent version" should be
"The Change page will show the most recent version".
Step 3. Should "select the version you want to publish from the Versions
list" be "select the version you want to publish from the Version
History list"?
By placing the tabs in an unusual place at the top of the page we
indicate that the page is unusual: users can edit the page. The tabs as
I propose are also providing different views of the same data, which is
what tabs should be used for. I did consider using the side menu, but it
is only a few hundred pixels wide at normal zoom. Once we have a page
three levels deep we have almost no space to place the edit-links. (We
also have little space to place any other links, but that is a slightly
different problem.) In addition, the page-editing links would get very
easily confused with the page-links.
The files need to support the same preview-publish work-flow as pages,
otherwise you could not preview a page that has a new image. By making
"Publish" the default I *hope* that people will not get too confused: if
you do not touch it you will get something like Wikipedia. Unfortunately
we need a preview-publish work-flow.
It is possible to have the file-permissions based on the content of the
page. It does make linking have a side effect, and I would prefer to
avoid side-effects, as they can be very confusing. I considered
something similar where the user explicitly linked to a version, but
that makes the common case (just updating and image and allowing
everyone to see it) very difficult. Hence placing the Publish check-box
with the file upload.
Thanks for the edits, Dan. I will fold them into the my draft :)
> By placing the tabs in an unusual place at the top of the page we
> indicate that the page is unusual: users can edit the page.
That is not so unusual. When I view this "Page Editing" topic, I see the
following context menu.
Group: GroupServer Development
* Topics
* Files
* Chat
* Members
* Charter
* Email Settings
* Manage Pages Manual
* Group Admin
Groups
* Exploring GroupServer
* GroupServer Admin
* GroupServer Announcements
* GroupServer Development
* GroupServer Marketing
* GroupServer Team
* PracticeNet
In the first list (which I know is still somewhat experimental), 5 out
of 8 items refer to a context where I can make changes.
> The tabs as
> I propose are also providing different views of the same data, which is
> what tabs should be used for.
Agreed.
> I did consider using the side menu, but it
> is only a few hundred pixels wide at normal zoom. Once we have a page
> three levels deep we have almost no space to place the edit-links.
[snip]
> In addition, the page-editing links would get very
> easily confused with the page-links.
The above device of two lists in the context menu addresses both of
these problems.
Regarding file permissions, I can see the need for a preview-publish
workflow. I am concerned that publishing a page version without
explicitly publishing all the associated file versions will be more
confusing than having the latter occur as a side-effect.
In addition, having "publish" as the default when uploading a file is
confusing. The user may well want to preview and not publish at that
point. Of course, the file won't actually be visible to others without a
link to it, but that may not be obvious either.
Surely, side effects are a good thing when they are almost certain to be
consistent with the main effect? In my car, opening and closing the door
has multiple useful side effects. In the car, the side-effects can be
over-ridden, but in our case, I don't even see the need for that. When,
in our case, would a user actually want to over-ride the side effect of
giving files the same permissions as the posts that link to them?
By the way, are you proposing to adapt one of the file-upload interface
designs you have done for the post context?
http://groupserver.org/r/post/2S7ExyY0u5dX46i1K9JnxU
The links for editing the page could go in the context menu, like the
group-links. For that matter, the links for a group could go in tabs ☺ It is
not a major issue, as it does not even alter the wording of the manual or the
functionality of any of the pages. I propose waiting until closer to the code
and see what we think of both.
Having a publicly-editable page necessitates file versions, as it allows quick
and easy fixing of vandalism. For example, rather than a nice picture of a
remote mountain hut you have an advertisement for shoes, and you want to return
to the picture of the hut. I also wish to avoid people losing data when they
load a file with the same name (hut.jpg, for example).
While versions are nice, I would prefer it that people would not have to think
about them except when they have to. When a person changes a page a version is
*implicitly* created. When someone uploads a file, a version is *implicitly*
created. The person modifying the page does not have to interact with the
versions as the new ones are published by default, which is what would happen
if versions did not exist (like profiles). Trying to be externally consistent
with systems that do not have a publish cycle is the primary reason for having
publish as default.
Not publishing the file by default would be very confusing. As would a system
based on the publish-permissions page version that links to it. In that case
all file-versions will have to be explicitly linked. (I am still unsure if I
want to allow this, even though it is in the manual.) If a file is uploaded
(just a minor change in a report, for example) the poor uploader has to go
through the page, looking for all relevant links and updating them. (This is
assuming that the person is even expecting a version control system, and
understands what it does and how it relates to pages and links.) We could add
a button to search for the links and update them, but then we have a publish
system similar to the one I propose, but it messes with with pages.
While not explicit in the manual, I am intending to use the same JavaScript
code for the multiple-file selector with posting files to topics and adding
files to pages.
As a side note, I tried to avoid the term "preview" in the manual, because the
publish mechanism is not really for previewing the page in the normal sense
(though it could be adapted for that purpose). It is actually for showing
another person the preview. The boss, for example. I do not expect it to be a
common task, which is another reason to have Publish as default.
Just quickly, a couple of scenarios:
Group Admin - The group admin seeks to add page specifically owned and easy to
access within the context of their forum:
- A group member-editable list of community links that is available from the
group home page as well as easy to find on any page within the group space
within two clicks.
- A admin-edited collection of aggregated community web feeds with a wysiwyg
applet that allows someone to easily input the feed, select how it is display
(headlines, excerpt, full-text) and where and how it is display particularly if
there are more than one feed or elements.
- A group member decides to append an editable file to a topic that allows
participants to take the discussion and build an end resulting document - not
unlike mediawiki/simple google doc - the key here is how the file is display
from the topic space on the web and how e-alerts about changes come back to the
group. Perhaps once a document in is added to a topic, every time someone on
the web adds a post, they see an editable version they can edit with that post
OR if they don't a simple line is added to the web and e-mail version stating
that no edits were made with that post to the topic.
- A group admin sees simple "edit" buttons on the forum home page and charter
page that allows them to make changes without having to use the current forms -
editing in consistent with how you edit other pages except the site admin has
the ability to pre-insert text and sections leveraging the existing database
scheme to encourage consistency but allow diversion.
- Pages could also have an applet function that expects to embed certain types
of "best of services" from across the web, such as Google Calendar, Flickr
collection, YouTube collection based on tag/keyword/author, an open to edit
Google Doc.
For E-Dem, use of an edit function for collaborative collections of content
tied to a specific group with group members having the permission to edit (or
just admins with charters/home pages) is of most interest. We use MediaWiki to
create community link pages tied to a forum and as you know we'd like to be to
display within the context of a forum "what's now" by displaying multiple feeds
on a page.
The key innovation with GS IMHO is the centrality of the "Topics" space
compared to the confusion diffusion of different sections in Basecamp for
example. So whatever happens with documents, changes/additions/deletions should
at a minimum generate a regular Topic post that highlights what happened.
Whether that is by default a daily/weekly digest or the possibility to generate
a new topic post for every "share now" final edit after a few hours of work,
sending the text of the changes with a link to the web version where it can be
viewed/further edited - keeping the experience in the central e-mail and web
feed experience for the group would be highly strategic. I would go so far as
to say a daily e-mail version of pages displaying changed feeds should by
default (you could turn it off) send a version of what's new to the topic and
preserve a snap shot for the web view. The simplicity of the Topic space
telling you everything that is happening in the group is something I enco
urage you not to lose.
Cheers,
Steven Clift
Steve,
I have designed the permission system for editable pages, but it is
not clear from may manual and use-cases. This is because what I
have *not* sorted is user-interface for changing the permissions. I
am going to look at that after the editing system has been tested.
Our first test will be with a restrictive use-case: all members of
the site will be able to view the pages, but only the site
administrators will be able to edit the pages, and view the version
history. This should limit the pain and suffering if I stuff anything
up ☺ Once we have the wrinkles sorted out of the system we will
widen the use.
The second test will be the same as your first use-case, Steve: group
administrators will be able to create and edit pages, while group
members will be allowed to view the pages and the version-history.
By this stage I hope to be getting a range of requests for specific
combinations of permissions. However, I can guess what some will be.
* Pages and history viewable to everyone, but editable by members
only. This is the same as your second and last use-cases.
* Everyone is allowed to do everything (a wiki-like system).
I am curious about what restrictions for adding pages people will
want. If anyone is allowed to add pages then I expect to see a fun
mess if our experience with topics is anything to go by ☺
http://forums.e-democracy.org/s/?s=ecan+water
http://forums.e-democracy.org/s/?s=gustavus
I also have been musing about replacing the charter page with a
page that is editable by the site administrator only. However, it is
a big enough change to warrant its own conversation, after we sort
out editable pages.
Most users of GroupServer work with it *only* as an email-list.
Anything that comes from a group and topic will be treated a message
from a person to the group. If it is a notification, rather than a
message from a person, then it will confuse people. Worse, the
messages from the group could be deleted out of hand. We must all
remember that the most frequently used command in Microsoft Outlook
is "Delete", which is often employed without opening the message.
Sending the user too much information is a dangerous thing with the
Junk button so close to Delete.
GroupServer has the ability to aggregate feeds: one is shown on the
home page of
http://onlinegroups.net/
We considered adding an interface to allow group administrators to
edit feeds. However, the priority for this interface is very low
compared to other components. Likewise, there are many other things
that could be added to pages, and we have been talking about adding
them since early 2005. Adding some of these to pages will be possible
with the page-editing interface. If some become popular then we can
look at adding user-interfaces that will make adding external
components quicker and easier.
The Manage Pages Manual now has a section on editing the metadata of a page
http://groupserver.org/groups/development/manage-pages-manual#manage-pages-manage-metadata
This includes copying, moving and renaming the page. These changes are outside
the scope of the version control system, unlike the tasks that I mentioned
earlier (except hiding a page)
http://groupserver.org/r/post/70YCEjIrwRpO8R5mPpzJPX
Below are the use-cases that I used to inform my design. They cover all the
metadata manipulation that I see carried out regularly. If there is anything
that I left out please let me know ☺
The model that I chose for the interaction is indirect manipulation. I thought
of creating an all-singing all-dancing direct manipulation interface — like
Windows Explorer or MacOS Finder file managers — but I decided against it, as
it is not what people expect when using the Web. I settled on a three step
form, where the syntax (object-action) is very similar to direct manipulation:
* Pages on the left,
* Actions in the middle, and
* Parameters on the right.
(Most object-oriented languages use this order, for what it is worth;
command-line tools are typically action-object.)
There is no distinction between pages and folders in the proposed system. A
page can contain other pages, but you cannot have a folder that does not have a
page. I did this because it simplifies things immensely. This is not explicit
in the manual, sorry. I will think about where to put this later.
*Manage* *Pages* *Use* *Cases*
Miriam Profiles a Company
Miriam's group maintains a list of company profiles. Miriam has a new
company to profile, so she copies the most recently edited profile
page. She then edits the copy, so it is specific to the company she
is profiling.
Lisa sees that the new profile has been created, but not added to the
main index. She makes a quick change to link the new profile to the
main page.
[Copy a Page, Change the Contents of a Page]
Kate Reorganises Documentation
The documentation for system is all on a single page. Kate decides to
split the documentation into multiple pages, after some people stated
that they they had difficulty navigating the documentation.
She keeps the existing page as the main index, and creates multiple
pages under the index. She then copies sections of the old main page
to the new pages, and sets up links from the main page to the new
pages. After checking all the pages she makes the new pages and the
new version of the main page visible.
[Add a Page, or Copy a Page and Move, Change the Contents of a Page]
Jane Reorganises a Site
After a card-sorting evaluation Jane decides to reorganise some
pages. She moves many pages, and rewrites some others. After the
changes she checks the planned information architecture against the
changes that she has made. She notices that there is a page that has
not been moved, so she makes the change.
[Move a Page, Rename a Page, Change the Contents of a Page]
Dan rightly pointed out that it is not clear why the list of pages on the
Manage Pages page is needed:
* The context menu, sitting to the left of the list of pages, is very
similar, and
* The user does not normally interact with the list.
The reason that I propose putting in the list of pages is that it shows the IDs
of the pages, and .it shows the structure of the pages better than the context
menu
The most serious problem with the context-menu is that it does not show the
identifier that is used to create the URL of the page. You need to know this
URL for copying, renaming and moving, as you cannot have two sibling-pages with
the same identifier. I propose a tree-view that shows the identifier of every
page, as well as the page titles.
The tree-view of pages should show all the pages, including the children of the
siblings of the parent page (cousin pages?). With the context menu cousin
pages are invisible. Hiding this structure is not a good thing when you are
trying to figure out the full context of a page.
All this musing about pages has me thinking about menus…
We propose that the permissions for the page-editing system should be editable.
Below I have copied the Change Privacy section from the manual
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-change-privacy
and provided a mock-up of the Change Privacy page. The interface presents two
sets of permissions: one for viewing the page and one for editing the page.
Behind the scenes there are four sets of permissions.
1. Viewing the page,
2. Viewing the history,
3. Editing the page contents, and
4. Editing the page metadata.
Dan, Alice and I can see situations where fine-grain control of these
permissions will be needed. However, most of the use cases come from grouping
these permissions together into Viewing and Editing, which is what is presented
in the manual section below. For example
* A traditional wiki would have both View and Edit set to Anyone;
* Pages in the online group for a committee would be viewable to anyone, but
editable only to members;
* A site-administrator may has sole responsibility for maintaining a library
of
reports, which are shown to site members only.
As ever, I look forward to any comments or suggestions ☺
*Change* *the* *Privacy* *of* *the* *Page*
To change a page, carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Change Privacy. The Change Privacy page will be shown.
3. Select the privacy settings for the View Page and Administer Page fields.
The former sets who
can view the page, while the latter sets who can change the page, and
manage the pages. The
three settings for the View Page and Administer Page fields are as
follows.
Anyone
Any person. The person does not have to be logged in or a member any
group.
Members
Only members of the group, if the page is part of a group, or members
of the site.
Administrators
Only administrators of the group and site, if the page is part of a
group, or
administrators of the site.
4. Click the Change button. The privacy for the page will be changed.
The permissions for administering the page cannot be be more lax than for
viewing the page. In
addition, the permissions for a page cannot be more lax than the page that
contains it.
The
following file was added to this topic:
I have made some prototypes of the Manage Pages page, as well as refined the
interface and manual somewhat. When opened, the Mange Pages page will look a
bit like the prototype below (using the GroupServer help as an example). On the
left is the tree of pages, and to the right of that is the list of actions that
can be carried out. Clicking on any of the actions will display the appropriate
fields on the right-hand side of the page. There is one exception: "View…" is
used to view the selected page. This is useful because some pages may not
appear in the context menu, and many not have any links to them!
The tree on the left is not needed for most operations. By default its primary
purpose is to make the user aware of the IDs of other pages, and to show people
the structure of the pages. I also think that it makes the page design more
sensible and it comes with little cost, as we need the tree for copy and move,
which I will post about soon.
The
following file was added to this topic:
I decided that Add makes more sense as an action within the Mange Pages page,
rather than my earlier proposal of a seperate Add page. This came about during
a long (off-line) discussion with Dan about how the page editing works.
Below I have posed a Add a Page view of the Manage Pages page, and the relevant
section of the manual
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-metadata-add-a-page
*Add* *a* *Page*
1. Navigate to the page you want to be the parent of the new page.
2. Click Manage. The Manage Pages page is shown, with the current
page selected.
3. Click Add. The Page Identifier, Title and Hidden fields will be shown.
4. Fill out the Page Identifier, Title and Hidden fields.
* The Page Identifier is used to link to the page. You will see it in
the location bar of your browser.
* The Title is shown in the title-bar of your browser, in the
navigation
bar at the side of the page, and at the top of the page.
* Select Hidden if you do not want the new page to be visible to
others.
5. Click the Add button. The new page will be created, and selected.
After adding the page, you may want to change the page contents.
The
following file was added to this topic:
Copying a page is complex, but hopefully picking sensible defaults will allow
common tasks to be completed quickly and easily. Below is a prototype Copy
interface, which is part of the Manage Pages page, and the relevant section
from the manual.
The
following file was added to this topic:
Copying a page is complex, but hopefully picking sensible defaults will allow
common tasks to be completed quickly and easily. Below is a prototype Copy
interface, which is part of the Manage Pages page, and the relevant section
from the manual
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-metadata-copy
*Copy* *a* *Page*
To copy a page carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Manage. The Manage Pages page is
shown, with the current page selected.
3. Click Copy. The New Page Identifier and
Destination fields are shown. The suggested
name for the copy similar to the original page,
but with -copy added to the end. The default
destination for the copy is the parent of the
original page. A page cannot have the same
name as one of its siblings.
4. Edit the name and the destination.
5. Click the Copy button. The page will be
duplicated, given the new name, and moved to
the specified destination. The new page will be
selected.
The
following file was added to this topic:
Renaming a page is quite simple, but I see a catch: people may get confused
between the title and the page identifier. I cannot think of a way to solve
this issue at the moment. Maybe when the weather cools down I will find a
solution!
Below is a prototype interface for renaming a page, and the relevant section of
the manual
http://groupserver.org/groups/development/manage-pages-manual/#manage-pages-manage-metadata-rename
[Sorry for double posting earlier.]
GroupServer.org
* Home
* Groups
* GroupServer
* Downloads
* Help
* Log Out
* Michael JasonSmith (profile)
Group: GroupServer Development
* Topics
* Files
* Chat
* Members
* Charter
* Email Settings
*
* Manage Pages Manual
* Group Admin
Groups
* Exploring GroupServer
* GroupServer Admin
* GroupServer Announcements
* GroupServer Development
* GroupServer Marketing
* GroupServer Team
* PracticeNet
I'll never understand what possessed my mother to put her faith in God's hands,
rather than her local geneticist. ― Gattica
Managing Pages
Change the Contents of a Page
To change a page, carry out the following tasks.
1. Navigate to the page that you want to change.
2. Click Change. The Change page will be shown. (Only people with the
correct permissions will see the Change link.)
3. Edit the contents of the page, which is shown in the Contents entry. You
can also change the Title and Publish fields.
* The Title is shown in the title-bar of your browser, in the
navigation bar at the side of the page, and at the top of the page.
* Check Publish if you want your new changes to be visible to the
groups of people listed on the Change page (which is the default). Uncheck
Publish if you want the currently published version of the page to continue to
be shown to others.
4. Click the Change button. Your change will be saved to a new version of
the page. Click View to view the version of the page page you have created.
Send this link to others to allow them to view your changes without publishing
the new version of the page.
Publish a Version of a Page
Only one version of a page is shown to people by default; you can publish a
version of a page to change what is shown by default. You may want to do this
because you have created a new version, or the current version has a mistake
and you want to return to an older (error-free) version of the page. To publish
a version carry out the following tasks.
1. Navigate to the page you want to change.
2. Click Change. The Change page will show the most recent version.
3. If you do not want to publish the most recently created version, select
the version you want to publish from the Version History list. The Change page
will show the selected version.
4. Click the Publish button. The version of the page will be published.
* If the version is already published the Publish button will not be
available.
* The published version will be visible to the groups of people
listed on the Change page.
View a Version of a Page
GroupServer.org records all versions of a page, but only one is shown by
default (published). You can view any version of a page by carrying out the
following tasks.
1. Navigate to the page you are interested in.
2. Click History. The Version History page will be shown. The date each
version of the page was created and who created each version is listed — as is
the version that is published.
3. Click View in the entry of the version you want to view. The selected
version of the page will be shown.
Compare Versions of a Page
Comparing versions of a page allow you to see the specific changes that were
made when creating the page. To compare versions to a page carry out the
following tasks.
1. Navigate to the page you are interested in.
2. Click History. The Version History page will be shown.
3. Select the first version you want to compare.
4. Select the second version you want to compare.
5. Click the Compare button. The Compare Page Versions page will be shown,
illustrating the different between the selected versions.
Link a Page to a File
If you want a page to contain an image, or allow people to download a document,
then you will need to link the page to a file. To link a page to a file carry
out the following tasks.
1. Navigate to the page you are interested in.
2. Add the file that you want to link to from the page.
3. Click Change. The Change page will be shown.
4. Select the text you want as the link text and click the Link button ― or
click the Image button. The dialog for selecting the link destination, or image
source, will be shown.
5. Select the file you wish to add to the page from the Files list.
* Select the published version of a file if you want all users to
view the page and file.
* Select a specific version of a file to the page if you are creating
a draft page that you only wish to show to specific people.
6. Click the Ok button. The file will be added to the page.
Manage Files
Add Files to a Page
To add files to a page, carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Files. The Files page will be shown.
3. Select the file you want to add to the page by clicking the Browse button
in the Add Files section of the Files page. The name of the file you selected
will be shown in the Add Files list. Repeat until you have selected all the
files you want to add to the page.
4. Check Publish if you want the new files to be visible to the groups of
people listed on the Files page (the default). Uncheck Publish if you want the
old versions of the files shown to others.
5. Click the Add button. The files will be added to the page. A new version
of a file will be created if a file of the same name is had already been added.
You will need to link the page to the file for others to be able to access the
files, either by links or as images.
Publish a Version of a File
1. Navigate to the page you are interested in.
2. Click Files. The Files page will be shown. A list of files and their
versions will be shown, showing the name of the person who added the file, and
the date the file was added.
3. Select the version file you wish to publish.
4. Click the Publish button. The selected version of the file will be
published.
Hiding Files
Files on GroupServer.org cannot be deleted, but they can be hidden, so most
cannot see it. To hide a file carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Files. The Files page will be shown.
3. Select the file you wish to hide. You cannot hide files that are already
hidden.
4. Click the Change button. The file will be hidden.
Change the contents of the page if the file is linked to from the page,
otherwise other users will see an error when trying to access the file.
Manage Metadata
Adding, copying, renaming and moving a page is carried out with the Manage
Pages page. It is divided into three sections. First, the page selector is used
to specify the page to alter. It lists all the pages that you can mange. Next,
the action selector is used to specify the action to carry out on the page. The
final section is used to set the parameters for the action.
Add a Page
1. Navigate to the page you want to be the parent of the new page.
2. Click Manage. The Manage Pages page is shown, with the current page
selected.
3. Click Add. The Page Identifier, Title and Hidden fields will be shown.
4. Fill out the Page Identifier, Title and Hidden fields.
* The Page Identifier is used to link to the page. You will see it in
the location bar of your browser.
* The Title is shown in the title-bar of your browser, in the
navigation bar at the side of the page, and at the top of the page.
* Select Hidden if you do not want the new page to be visible to
others.
5. Click the Add button. The new page will be created, and selected.
After adding the page, you may want to change the page contents.
Copy a Page
To copy a page carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Manage. The Manage Pages page is shown, with the current page
selected.
3. Click Copy. The New Page Identifier and Destination fields are shown. The
suggested name for the copy similar to the original page, but with -copy added
to the end. The default destination for the copy is the parent of the original
page. A page cannot have the same name as one of its siblings.
4. Edit the name and the destination.
5. Click the Copy button. The page will be duplicated, given the new name,
and moved to the specified destination. The new page will be selected.
*Rename* *a* *Page*
To rename a page carry out the following tasks.
1. Navigate to the page you are interested in.
2. Click Manage. The Manage Pages page is shown, with
the current page selected.
3. Click Rename. The New Page Identifier field is shown,
with the existing name in the field.
4. Edit the new name. Note that the new name cannot be
the same as the name of the sibling pages.
5. Click Rename. The page will be renamed.
The
following file was added to this topic:
Sorry for copying too much out of the manual in the previous post. I will stop
doing that now, to prevent further mistakes. (I blame the heat.)
Moving a page is a bit like copying it, with the renaming-action removed. This
is reflected in the prototype below.
The
following file was added to this topic:
The final note for today, I promise!
Hiding is what I prefer to do instead of deleting. The problem with deleting is
that it allows people to lose data. This is a Bad Thing. When you hide
something you have the option of showing it again. For the most part the
document is out of sight and out of mind. However, you can get the document
back if you need it back. The trash on the desktop is a place to hide
documents, for example.
In the page-editing system, hiding will prevent the page being listed in the
menus, and only people with the Edit privilege will be able to see the page (in
the tree view of the manage pages page).
On 6 Jan 2009, at 20:36, Michael JasonSmith wrote:
> The final note for today, I promise!
>
> Hiding is what I prefer to do instead of deleting. The problem with
> deleting is that it allows people to lose data. This is a Bad Thing.
> When you hide something you have the option of showing it again. For
> the most part the document is out of sight and out of mind. However,
> you can get the document back if you need it back. The trash on the
> desktop is a place to hide documents, for example.
>
> In the page-editing system, hiding will prevent the page being
> listed in the menus, and only people with the Edit privilege will be
> able to see the page (in the tree view of the manage pages page).
But what if I really, in fact *do* want to delete a page? Will I
have that option?
Graham Freeman
Cernio Technology Cooperative
www.cernio.com
<email obscured> (Email/Jabber)
+1 415 462 2991 (Office)
Hi Graham,
The ZMI administrator of GroupServer will have the ability to destroy data. I
expect the need to be rare, but I will keep a watching brief in case the
equivalent of Empty Trash is needed ☺
Below is a prototype for the Change page. It is designed to carry out the
normal page-editing tasks
http://groupserver.org/groups/development/manage-pages-manual#manage-pages-edit
At the top is a series of tabs, mentioned earlier but drawn for the first time.
The Change tab is currently selected. The title is below that repeats the verb
Change, the page title, and page version that is being shown.
A brief change-history appears after the title. In the example below I show the
changes made on one day (the times were taken form the edits to the manual
yesterday). Each version notes
* If the version was published (or just created)
* Who created the version, and
* When the version was created.
Each version has the option to view it, and most have the ability to switch to
them, if you want to create a new version of the page based on one that is
older. In the example below the most recently created version is being changed.
The “important” versions are emphasised in the history list. The important ones
are those that were published and the version that is being changed. To reduce
the number of versions that are shown the published versions are disclosure
buttons, with the unpublished versions contained beneath them. In the example
below the currently published version has been opened, showing four versions.
The earlier version published at 09:29 remains closed.
The title of the page is… the title. Changing the title will create a new
version. The title is distinct from the page-identifier, which is part of the
metadata, and is altered by the Rename interface that I posted yesterday
http://groupserver.org/r/post/1bibG2VUSXIDYS6flsQBzI
The Contents entry follows the title. It uses WYMEditor, like we do on the
Change Profile pages. It will probably need to be a lot taller than what is
shown in the example below. By using a good editor I hope to reduce the need to
preview a page. The example below shows text from the Keeping Track of
Conversations page of the User Guide
http://groupserver.org/help/participation/keep_track/
The Publish option appears at the bottom of the Change page, along with a
statement on who will see the published version. By creating a version, and not
publishing it, you can create a draft. This draft can viewed by clicking on
View next to the version in the History list at the top of the Change page.
Unlike a preview system, others can be sent a link to the draft version of the
page. Alternatively, the user may want to store an incomplete version to reduce
the chance of data-loss. The privacy statement is based on the settings on the
Change Privacy page, it states who will see the published version of the page,
and who will be able to see the names of those that have changed the page (on
the History page).
Finally there is the Change button, repeating the verb Change from the tab and
title.
Please feel free to send me questions or comments? Version tracking is not
something that most people are used to thinking about, so I am very happy to
clarify anything. Thanks to Dan and Alice for all their help with designing
this page.
The
following file was added to this topic:
Below is my prototype History page. It is linked to from the main tab, and from
the Change page. On the left of history page is a series of tabs labeled with
temporal groups in ascending order:
* Today
* Today and yesterday
* Past week
* Past month
* Past year
* Ever
The temporal groups are based on an idea that if we have a name for a unit of
time then it is a useful chunk to deal with. (The “Past Fortnight” chunk is
missing because “fortnight” is not common in American English.) All the groups
include the most recently edited version — or every group is a supper-set of
the one higher-up the list, if you like to think of it that way. While this is
not a common way of splitting up temporal lists it makes more sense to me and
it is worth a trial (in an interface that few will use, so it will do little
harm). If it proves successful we could look at using it elsewhere, such as the
Summary of Posts page ☺
On the right are the versions that belong to the selected temporal group. The
text representing each version is the same as that in the History list on the
Change page
http://groupserver.org/r/img/1474-2009-01-08T032247Z
The text includes the name of the person who created the version, the date that
the version was created. and whether the version was published. The published
pages are emphasised because they are more important than the other pages, and
like all pages they have options allowing users to view the version, or change
the page based on the version. (You need edit permissions to see the change
link.)
There are two radio buttons to the left of each version. These are used to
select the two versions for comparison. My current plan is to display a simple
diff of the HTML source of each page, but there is potential there to do
something cool, like showing the differences between the rendered documents.
Any questions or comments? Has the heat sent me completely mad? What interfaces
will I design if we get *over* 35°C‽
The
following file was added to this topic:
The phrase in my previous message should have been
every group is a super-set of the one higher-up the list
Not “supper-set”. Sorry.
Below is a prototype of the Mange Files page. The page is divided into a
section for adding a file, and one for managing the files that have been added.
At the top is the section for adding a file. It has a file-selector and a
button for determining if the file should be published. If a file with the same
name has already been added to the page, then the new file is added as a new
version of the file. Otherwise a brand new file is added to the page.
The bottom section lists the files that have been added. The example below uses
files from the GroupServer download page. The first file,
groupserver-1.0alpha.tar.bz2, has four versions; the second file,
gs-download.png, has one version. For first file, the user has the choice of
either selecting which version to publish, or hiding all versions. With the
second file there is no publish button as there is only one version; the file
can be hidden, however.
The
following file was added to this topic:
Tomorrow I will get a prototype page for editing going. Tonight, I will post
what a functioning Change page looks like on my test platform ☺
The
following file was added to this topic:
Sorry about the lack of the promised page-editing page for you to play with.
Unfortunately a nasty Unicode problem cropped up. It is fixed, so I should be
able to put something up for you on Monday (NZDT).
I present the sandpit, a page that demonstrates the page editor:
http://groupserver.org/groups/development/sandpit
The page to change the sandpit page
http://groupserver.org/groups/development/sandpit/edit_page.html
Currently the content can be changed, which creates versions that can be
published and viewed. Permissions can be restricted, they are not in the case
of the sandpit. It has permissions like a wiki where anyone can change
anything.
Still to come are tabs, the history page, the manage-pages page, and
enhancements to the list of versions on the Change page.
On Tue, 2009-01-20 at 16:48 +1300, Michael JasonSmith wrote:
> Still to come are tabs, the history page, the manage-pages page, and
enhancements to the list of versions on the Change page.
Seems to do the job so far, from my initial wee play :)
I am glad that the Change page worked for you, Richard. Alice also had a
play. She was not logged in at the time, so her edit was attributed to
"an anonymous user".
On Tue, 2009-01-20 at 17:24 +1300, Michael JasonSmith wrote:
> I am glad that the Change page worked for you, Richard. Alice also had a
> play. She was not logged in at the time, so her edit was attributed to
> "an anonymous user".
Heh, does that make it a 'wiki'?
Really, really nice, Michael. Thanks also to Andrew Groom for your work
on this. Great to see it live!
Dan
Richard,
The page editor is designed to support the same tasks as a wiki, while
not being a wiki as most people think of it. There are three main
reasons that the page editor is not a wiki: it can have restrictive
permissions, it uses HTML, and it supports a hierarchy of pages.
The permission-system for the page editor is more flexible than a true
wiki. The sandpit (sandbox to our North American friends) has the same
permissions as a true wiki, with anyone able to do anything
http://groupserver.org/groups/development/sandpit/edit_page.html
However, the page editor can be set up (using the ZMI currently) to
restrict who can see the page, old versions, and edit the page. Each of
these permissions can be altered independently of each other.
The language used to create content in the page editor is HTML, rather
than a wiki language. Once you know HTML you can use it with many
systems, from ASP to Zope, as it is based on a standard. Each wiki is
different. Once you know Media Wiki you can use it with Media Wiki, but
not necessaryly with a system such as MoinMoin. HTML has a reputation
for being complex, but I have never been convinced that it is more
complex that a wiki language. Wiki languages become especially
problematic when used for pages that have tables, floating images and
other complex elements.
Finally, the design for the page editor supports a hierarchy of pages.
http://groupserver.org/r/img/1465-2009-01-07T022209Z
In a wiki all pages are stored in the same folder.
Yup, looking really good, Michael. Well done, that man ! :-)
On Tue, 2009-01-20 at 16:48 +1300, Michael JasonSmith wrote:
> I present the sandpit, a page that demonstrates the page editor:
> http://groupserver.org/groups/development/sandpit
> The page to change the sandpit page
> http://groupserver.org/groups/development/sandpit/edit_page.html
> Currently the content can be changed, which creates versions that can be
published and viewed. Permissions can be restricted, they are not in the case
of the sandpit. It has permissions like a wiki where anyone can change
anything.
>
> Still to come are tabs, the history page, the manage-pages page, and
enhancements to the list of versions on the Change page.
Shucks, thanks Andrew *blush* ☺
While they may not look much, the tabs are now present, so you can switch
between the View, Change and History pages quickly and easily. The Sandpit
shows the tabs at the top of the page, just below the main menu and above the
page title:
http://groupserver.org/groups/development/sandpit
The History page is now present. It currently shows a list very similar to the
Change page. Eventually the History page will show the complete history, while
the Change page will show a truncated list. Both the History and tabs and
figure out what the person viewing the page should be shown, as not everyone
should be shown all links.
Enjoy ☺
I have committed a couple of changes to the Change page: a small alteration of
the history list, and the addition of a privacy statement..
The first change is to reduce the number of items that is shown in the history
list on the Change page by default. Now it shows all versions between the
selected version and the most recently created version, or all versions between
the most recently published version and the most recently created version. The
History page still shows all versions.
The other change is to add a privacy statement to the bottom of the page, just
before the Change button. It states who can see the changed page and the
different versions. Below is four different privacy statements. More than four
privacy settings are possible, but the messages below give you an idea of what
is possible.
- *Anyone* can see the published changes you make to the
page, and they can see past versions of the page and
unpublished changes.
- *Anyone* can see the published changes you make to the
page. Only administrators can see past versions of the
page and unpublished changes.
- Only members of this site and administrators can see the
published changes you make to the page.
- Only members of this site and administrators can see the
published changes you make to the page. Only
administrators can see past versions of the page and
unpublished changes.
The idea behind the privacy statement is to show you the right information (who
can see what) at the right time (when you are making a change). I use bold if
the "Anonymous" user can see something, as this is the least private setting. I
do not say who can change the page, because the information is not needed at
the time you are making a change; this information will be placed on the
Privacy page.
If people like the above statements I may detour off and add them to the Topic
and Start a Topic pages, which also need a clear and timely explanation of the
group privacy settings.
The
following file was added to this topic:
I have resumed work the Page Editing project. The goal of this project is to
allow some simple content editing and page management, to about the same level
as what is possible as a wiki. The page-editing sandpit demonstrates what is
currently possible with the system
<http://groupserver.org/groups/development/sandpit> — but you have to be logged
in to change anything.
I have added a group-server skin to the WYMeditor, which is the core code that
we use to allow people to edit the content of the page. I have also updated the
version of the WYMeditor we use from 0.5 Beta 2 to 0.5 Release Candidate 1. I
will deploy the update in the next day, and tell you all when it is done.
The next phase of the project is to give it to people outside the core testers.
I hope to do this by Wednesday. The system will not have many page management
features, but it will allow simple page editing.
Hi, I have an interest in being able to use the site page as a
light-weight website, for people who want to do a little bit of
controlled publishing, but not enough to warrant a full website.
The existing HTML chunk usable by some people, but as far as I can see
there's only one location for it (http://hpvotago.onlinegroups.net/);
possibly there should be something similar on the group page that can
be customised. It might be difficult to fit a whole sidebar in there,
so perhaps just an editable title bar, like the group description,
where we can put links to the new locations we've created, perhaps?
Hi Jim,
You are totally right, the Page Editor that I rolled out on Friday only has one
page in it. In addition, it has no ability to add more pages. However, the Page
Editor does happily work in groups
<http://groupserver.org/groups/development/sandpit>, but few groups have one ☺
If you directly send me the names of the pages you want, and where you want
them, I will be happy to add the pages for you.
I deliberately left off the ability to add and manage pages and files when I
rolled out page editing. Dan and I thought that adding the Manage Pages page
would delay the release of something that is useful as it stands.
I do have plans for adding the ability to add pages. You can see my prototypes
for managing the pages in the following five images, starting with Add
<http://groupserver.org/r/img/1466-2009-01-07T023412Z> (Sorry about the two
Copy images). The draft manual contains help on managing pages
<http://groupserver.org/groups/development/manage-pages-manual#manage-pages-manage-metadata>.
The complexity of managing a hierarachy of pages may not be necessary. I could
crate a Wiki-like system, with all pages at the same level (one step below the
root page). The user could use a check-box to specify the pages that appear in
the context-navigation, which appears on the side of the page.
