Read only wiki

[opn]

Now with the new authentication functionality added to wiki we can take another look at the behaviour of wiki when a user is not logged in.

At present any user can "edit" any site with changes reflected in the browser cache. This results in a lot of confusion with new users. It also makes it impossible to direct casual uses to a wiki site and expect them to be able to read the content. For wiki authors this is not a problem as they understand the features of local edits / browser cache / and multiple sources of origin. However a casual web user understands none of this, clicks of some links, accidentally moves or deletes content, and the site soon becomes unreadable - the next time they go to the site the content still appears deleted. The process to remove local edits is complex and buried in the current interface.

The proposed solution (discussed in last weeks Hangout) is to make a site in which the user is viewing and not logged in, fixed, so that editing paragraphs and dragging and dropping them is no longer possible.

Dragging and dropping a page flag on a tab prior to forking a page would still work - so that a logged in user can fork pages and then edit them.

Currently I can see no benefit of being able to edit sites that a user does not own (in any circumstance) - however this functionality could be retained when a user is logged in to a site of their own, or if they were to unlock a foreign read only site by interacting with the padlock in some way - say to click a link saying "Edit in browser cache" which would then unlock a site without requiring any other form of authentication with any changes" being saved only to browser cache.

However I cannot find a use for this, and not making a strong distinction between a site you own, and a foreign site owned by another user is a source of a lot of initial confusion to new users. For this reason it may be worth considering strengthening the distinction in a users mind through some extra visual feedback.

A users own site, when logged in (and therefore in editing mode), should look different is some clear visual way from a read-only site. Foreign sites in read-only mode would not be editable in any way, and look the way they do currently. The users origin site, when logged in would only allow eiditing, and drag and drop of paragraphs etc - and would look significantly different (perhaps the default page background colour was not white or ....

[WardCunningham]

We have taken a new approach by distinguishing authentication from authorization (person vs. permission) which might make this a good time to rethink our related interaction models too.

There are two cases where we have usability traps that don't go away with experience. I will describe them with metaphor. Think of the lineup as papers on a messy desk.

• I'm reading but leave ink smudges on papers
• I'm reading, get a phone call, and want to write immediately

We want work to go quickly and smoothly in every case. If we make a big change then it would be nice to handle these cases better too.

[opn]

• I'm reading but leave ink smudges on papers
  Unlock the padlock, click an appropriate button and type

• I'm reading, get a phone call, and want to write immediately
  Unlock the padlock, click an appropriate button and type

The main issue here remains the same. Wiki is currently unreadable. I do not and will not send the majority of people links to wiki. They will move a paragraph, and inadvertently create an unreadable mess. If I can turn this off in some way, I can start using wiki for actual sites, rather than just R&D spaces for trained writers.

[WardCunningham]

Of course we could say the same of excel or power point but those are shared frequently.

[opn]

Sharing an excel or powerpoint project is a good example. I can share Fedwiki in the same way - that is with other people familiar with the software and motivated to create content.

But the situation is radically different with someone expecting to view / read web content. It is much easier to accidentally change content of the viewed information in Fedwiki. Simply by scrolling a page inexperienced users frequently move a paragraph, losing and deleting content which they cant find again. It is significantly harder to edit either excel or power point files.

In addition both those softwares have a read-only mode for presenting the information on the web in which the viewer cannot alter the displayed content - therefore I can create content in Powerpoint and then share it with inexperienced users. I cannot (yet) do that with Fedwiki - hence the feature request to provide a read-only view of wiki.

[opn]

Taking a look at the interface today, and considering the issue of making a clear distinction between a browser tab in which an author is logged in to their site of origin, and a read-only view of another authors wiki site - the simplest way to visually create a clear distinction is to use the bottom bar.

The above appearance would be in authoring mode for a user that is logged in to their origin site and able to edit.

While this would be the appearance of a read-only view of a site when the user is not logged in to the site of origin. In this read-only case the user would not be able to move paragraphs with drag and drop, nor would they be able to double-click and edit an item.

I suspect this would fix the majority of issues currently on mobile as well - as the main issue is that a user cannot scroll on mobile when reading content due to the touch event being trapped and used to move paragraphs. If this is turned off for all users who are not logged in mobile content should be viewable.

[WardCunningham]

I had a go at coding the read-only option in the client-side code. I found three lines that could be put inside an if-statement to make read-only switch on and off based on some aspect of the security state.

https://github.com/fedwiki/wiki-client/blob/master/lib/refresh.coffee#L278-L280

Rather than figure out the control logic I just commented out the three lines expecting to get a read-only wiki. If I inhibit dragging, merging and adding, I reasoned, that would be a good start on read-only. Could it be that simple?

Well, my experiment was inconclusive. I refreshed the tab, saw wiki page-frames draw, but got just blank space after that. No content what so ever. I say inconclusive because something unrelated must have gone wrong. I uncommented the lines but still got blank pages. What's with that?. I'm running wiki@next but haven't built for that yet so that is where I expect I'm getting into trouble. I want to go after this but I'm going to have to approach this with a clear head and a few hours to work.

I mention this because we are talking about linking two parts of wiki that are plenty complex in their own right: security and refresh. I suggested the ink-smudge vs. quick-note analogies because I wanted to have those distinct cases in mind as I start moving things around.

[opn]

I'm not clear about these use cases. Let's explore them in more detail:

• I'm reading, get a phone call, and want to write immediately

My understanding is there are two existing ways to do this - a local wiki is running, or you are logged into another tab / can login with two clicks to your own site and start writing. Both these techniques suffice for me / the people I write with.

If there is a more advanced requirement, I can't specifically see one. I think I know what you mean... it is a form of annotation of someone else's content that you are looking for? personally I would remove this feature in the current version and simplify things.

If this is demanded by users, or something you feel central, then interacting with the padlock to unlock another authors site and then interacting with the dialog presented could be something akin to providing a choice between the usual auth schemes (such as Gmail / GitHub / Twitter) - but with an additional option for "Annotate in Browser".

The latter would enable the current behavior so that changes create the local changes modifications in browser cache. This option would need to go with a clearer way to bring these local browser modifications into your own wiki (I'm still not clear how to do that as a fork does not achieve this?).

• I'm reading but leave ink smudges on papers

I'm not quite sure what you mean by this?

[WardCunningham]

If I'm looking at your site and it is hosted on my server where I have a login but not authorization to write on your site then when I want to write a note I just click the lock, click ok from the provider, and start writing. But how does this work if I am not already logged in to the provider or if I don't have an account with the provider configured by the administrator of your host? This is yet to be explored.

I think we can work something out but it will take some thinking.

[opn]

I don't understand the issue. Let's see if we can break it down.

Let's take the current behaviour - let's call it LocalEditAnything. The proposal is that we remove this behaviour as the default, so that a locked site becomes ReadOnly. ReadOnly means that the drag-paragraph, and double-click-to-edit events are not available.

We want to provide "Write-Immediately-Annotation" - to be clear I think this is a bad idea, and best provided by another service - and we provide this by creating / adding a new minimal form of login that requires no authentication. Perhaps you simply unlock the padlock and dismiss the provider authentication dialogue (or choose an "Annotate in Browser" button / link).

This does not require any provider, nor any password - it simply turns on the annotation mode that we currently have as a default - ie the LocalEditAnything mode. In this mode any edits a saved in the local cache and create a yellow halo as it does at the moment.

Locking the icon again would return to a true Readonly mode disabling the wobble events - ie double-click-editing and paragraph move.