The Myth of "Read Only" -- Let's Differentiate & Get Better

[@TiddlyTweeter]

This thread springs off from a previous one at https://groups.google.com/forum/#!topic/tiddlywiki/JeuinlhzMNU in which Ton Gerner and Stef contributed good stuff.

Stef's economical solution to quick "Read Only" settings got me thinking.

WHAT IS "READ ONLY"?

The issue with enabling "read-only" mode in TW quite often comes up.

TBH I find it a less than an optimal way of thinking about the issue. Its too crude to the reality.

What IS the issue? Of course, its switching off access to functionality, usually through CSS, so users don't get access to some stuff. It makes their experience cleaner and to the point. It means the author can control their public presentation.

But WHICH functionality is switched off? Its not all one thing. There is no such thing as THE way to do this. There is no such thing as a definitive "Read Only" TW so long as you have a live Javascript machine under your mouse.

Different situations require differential accommodations. So, I think "Read Only" is actually confusing the issue, though its a fine panhandle, it does capture one general idea quite well, yet its also a bit of dumbing-down.

USE CASES

We can do better ...  Here are a few ... There are many others ...

#1 - A TW of a Novel where you want to allow users to add annotations & bookmarks but not to be able to directly create new Tiddlers, or ever see anything starting "$:" With simple text search, no advanced.

#2 - A TW that is always one main transcluding tiddler ("the page"). Additions allowed through a modal editor but result are always constrained to appear in that transcluding tiddler. (ToDoNow plugin by Telmiger approximates this model)

#3 - A TW that is used to present one Tiddler as an apparently static page via a permalink. FullScreen. No menus. No Sidebar. No Editing. No Save. No internal links.

You get the idea.

GLOBAL SOLUTION?

Stef's approach to get together in one place many settings in an economical form was really suggestive of possibilities.

I was thinking that solution could be expanded with more options. Like removing all menus etc.

But also add, IF it were possible to have checkboxes next to every item. Then the VARIABLE NEEDS evident in the Use Cases above, and more, could become doable.

My problem is I am not a programmer, but I can see we could get a lot more fine-grained on "Read-Only", which should really be called something More Positive like: "User Edition Settings".

Best wishes
Josiah

[Lost Admin]

I can add even more complexity of use-case(s).

A version that is editable and when saved generates a static html version that the public uses. This one requires an actual http server and is more of a content management system.

[@TiddlyTweeter]

Going to static is less problematic because the result is no longer TW, but behaving children.

I DO agree that attention to the richness of "outgate settings" is of great merit.

Josiah

Lost Admin wrote:

[Mat]

Yeah, one could imagine an endless degree of granularity for various settings.

But the only important question is: What do you or others want to control?

<:-)

[@TiddlyTweeter]

Ciao Mat

right. its almost infinite. but not quite, fortunately.

I was interested in how far you could push Step's thing, though with each option selectable (the possible nesting would be a complexity) and add more to it.

There is also the issue of doing this directly through CSS stylesheets, rather than  one by one styles.

If we can define a few use cases what is needed it may get clearer where the utility direction lays. Is it, really, style by style? Or is it some global CSS?

Josiah

Mat wrote:

... the only important question is: What do you or others want to control?

[Lost Admin]

I don't know what I want to control.

Mostly I use Tiddlywiki for myself. The one case where I use it for multiple people, none of them need any sort of write/update ability. So generating static pages works for me so far. I'm sure that will change in the future.