allows to define behaviour when last tiddler in story is closed

[tobibeer]

demo: http://tbdemo.tiddlyspot.com/#OnEmpty

This modification to $:/core/modules/widgets/navigator.js allows to define the behaviour of TiddlyWiki when the last tiddler in the story is closed by setting the text of $:/config/Story/OnEmpty to either of:

• keep
  • will keep the last tiddler open
• default
  • will open the default tiddler(s)
• open:foo / show=foo / open     foo    
  • either will open the tiddler foo
  • in other words
    • the first 5 characters are truncated
    • the rest is trimmed

[pmario]

If I "want to close" the "OnEmpty" tiddler, I don't get any feedback. -> so the TW looks broken. Any other tiddler can be closed.

Close all button doesn't work anymore.

IMO there needs to be a way for the reader to decide to close the tiddler.

It's nice that a TW author can define a default tiddler and forces me to read something a 100 times. ... But there may be a point, where I as a reader want to disable this behaviour.

[tobibeer]

If I "want to close" the "OnEmpty" tiddler, I don't get any feedback. -> so the TW looks broken. Any other tiddler can be closed.

Whomever the author is — in this case me — decided that there is no empty display. Hence, nothing is broken. So, close-all works precisely as intended! It behaves the same way as closing the last tiddler.

The reader is not the one deciding here. It's the author.

there may be a point, where I as a reader want to disable this behaviour.

An author of a site gets to decide how a site behaves, not a visitor. If visitors demand "I want that blank canvas", maybe an author may feel tempted to cater for it... otherwise, maybe not.

Please don't always think or expect "default" behavior... allow TiddlyWiki to be what YOU or I want it to be... even if that means to NEVER show an empty canvas, someone asking "What just happened?" ...maybe nobody will even notice.

[pmario]

But the problem is. If the is a tiddler close button and I click it. It doesn't close. ... that's an issue.
So if you can't close the tiddler, there shouldn't be a close button.

[tobibeer]

But the problem is. If the is a tiddler close button and I click it. It doesn't close. ... that's an issue.

I don't quite see how it is an issue when it is the desired behaviour.

Although a poor analogy, if you don't like some wiki having a red background, you can't say it's an issue, even though you may find it confusing, but it's really not your decision to make.

Now, we could do stuff like change that close button to a home button instead or disable it when it's not going to do anything. At the moment I would say that would overly complicate templates.

Another option may be to have some "empty story message"... but then, directly rerouting a visitor to where one intends to send him anyway makes more sense to me.

[pmario]

I don't quite see how it is an issue when it is the desired behaviour.

As a user, that sees the TW the first time, I don't know, that it is a desired behaviour. Since I don't get feedback if I close the "permanent tiddler" it's confusing.

[tobibeer]

This is not about changing defaults.

It's about an ability to define the behavior as an author so that things operate the way you want them to, e.g. like on a website, where I never want visitors to stare at an empty canvas, it's simply poor ui. I also don't necessarily want all startup tiddlers to open up, but rather only a home-page / dashboard when the last one is closed.

"All TiddlyWikis behave like foo" is no meaningful expectation. Not being able to close that last tiddler for sakes of "but I want to click, click, click", really isn't... a cause for concern.

[tobibeer]

@pmario: May I ask: What precisely are you after? What this this pull request provides is pretty straight forward. Why suggest anything was broken when the intention is to provide exactly this behaviour? ...in a rather sensible and flexible manner, if I may say.

I can sure turn this into a plugin or just some executable tiddler hijacking core components, at which point the first thing I would do is make a pull request for a standard hijacking interface, so that not every plugin goes about inventing its own, perhaps inconsistent ways, over overwriting stuff.

var myhandleCloseTiddlerEvent = $tw.utils.hijack(NavigatorWidget.prototype.handleCloseTiddlerEvent, "my-id", function(foo, bar, baz){
var result = myhandleCloseTiddlerEvent.apply(this,arguments);
do(foo);
return result;
});

For this pull request it would have been required to do the above two times for no good reason whatsoever, if you ask me.

I think hijacking should be avoided as much as possible. Not providing core features means to encourage developers to eventually having to, at times bluntly, overwrite insufficient modules... and so we're eventually creating a much bigger mess to handle.

[pmario]

I think, the idea to have a dashboard like tiddler, is ok.
I know, that your pull request has the desired behaviour. I just think it can be improved.

If I click the "close all" button, as a user I expect that everything is closed. If one tiddler stays open and I don't get any info, why, imo it's broken. It may be the authors desired behaviour, but how should the user know?

I think triggering a notification is obtrusive. ... So we need a more subtle way to tell the user, that "this tiddler" is marked as a fallback tiddler tiddler, if otherwise the canvas would be empty.

I think, if onEmpty is part of the core, it needs a setting in the control panel, similar to "Default tiddlers", so we have the possibility to change it and also translation, needs to be possible.

We have the "home" button and now a "close the last tiddler" and the "close all" button have a similar behaviour. ... I don't like the inconsistency, that is introduced here.

IMO "Default tiddlers", the home button and onEmpty have to be combined in a generic and consistent way.

[tobibeer]

If I click the "close all" button, as a user I expect that everything is closed. If one tiddler stays open and I don't get any info, why, imo it's broken. It may be the authors desired behaviour, but how should the user know?

I get your point. I didn't want to overload it with options, other than those that came quite naturally. Of course, that configuration tiddler could have a field called "close-all" which when set to true truly does close all. The point of this modification, however, was to never stare at an empty canvas. So it was pretty much the only choice for close-all to behave in a way that is consistent.

I think, if onEmpty is part of the core, it needs a setting in the control panel, similar to "Default tiddlers", so we have the possibility to change it and also translation, needs to be possible.

To be honest, I didn't even see OnEmpty as a tiddler that is shipped with the core... but rather one you create when you need it.

I don't think everything that works needs a section in the control-panel, especially not when it's a one-time setup that you only need when you plan on using TiddlyWiki as a website. Sure, things that get you started deserve that prominent spot, i.e. SiteTitle.

Perhaps there could or should be some additional "Website" / "Publishing" package / tab that comes with additional settings to cater for that usecase, e.g. "SinglePageMode" or some "OpenTopStoryView", etc...

The ControlPanel is probably the place where most people look first to figure out what's customizable, rather than some documentation on TiddlyWiki.com.

On the other hand, there are certain things that may need changing in terms of customizability. For example, I don't think the $:/tags/SideBar apporach is good when coupled with the actual tab-templates... as it takes away upgradability simply because you wish to reassign tabs from primary to secondary and vice versa, or reorder them. This would be something I am much more concerned about rather than not being able to close some last tiddler as a visitor to someone else's wiki... or site.

We have the "home" button and now a "close the last tiddler" and the "close all" button have a similar behaviour. ... I don't like the inconsistency, that is introduced here.

I really don't see it as an inconsistency. I wouldn't be confused as an owner / user, because I had set it up that way. I wouldn't be confused as a visitor because what do I know how someone set up their wiki. Everything is and should be possible up to the point where you wouldn't even think you're looking at a TiddlyWiki.

I would rather be curious and wonder "Oh, what's that? How did they manage to do that?" sini-Kit had set up his shop so that there pretty much only was an individual tiddler's ViewTemplate. Closing the last tiddler pretty much left you with an empty display. My point is, you should have certain expectations as to how an empty TiddlyWiki works, but really, not at all, how a customized one does.

IMO "Default tiddlers", the home button and onEmpty have to be combined in a generic and consistent way.

To me, there is a distinction between a "home" tiddler and startup tiddlers. One serves more as a fallback whereas the others serves more as a welcoming package.

[sukima]

As a UX zealot I would say the feature is fine as long as it also disables / removes the controls that would then do nothing. Having a button that does nothing (no feedback) or does something different then it's text will make the user feel like it is broken. So if you never want an empty TW then the last tiddler should have no close button and the "close all" button should be disabled or rephrased to something like the "home" button since the two are vary similar.

Also I presume this feature is a plugin? As a casual TW user who uses it as a notebook usually I would not want this feature. However, I can see it's use in things like choose your own adventures and other context specific uses where the close all function would not be desired.

[tobibeer]

@sukima, using TiddlyWiki as a website is a very common usecase, after all TiddlyWiki is made for the web and caters for it quite nicely... if SEO is not you biggest concern.

So, try not to think of using a standard TiddlyWiki as a user here. It's equally poor to hide relevant information in some info-panel that is expanded via some dropdown and then clicking on some button.

The open tab also shows a close-all button, even if all are already closed.

You see, there are lots of little stepping stones. I honestly don't see these things in plugin-land. It would be(come) a big mess to get all the little switches you want from all the different sources that have them... on top of all things, overriding core components and modules.

If that close button was hidden, I can already hear you asking "but where is the close button"? Again, if I want my wiki to behave like that, then you should really ask: "Curious, there is no close button. Why is that?"... instead of thinking of this as either a bug or poor ux.

So, what is the tradeoff here? To me, having a visitor staring at a blank canvas makes for an a lot poorer ux than gently forwarding them to a good starting place.

[Jermolene]

I understand the need driving this proposal, but I'm not comfortable with the idea of modifying the navigator widget with a special attribute for such a narrow edge case. The issue of the close button still appearing is also problematic.

Would it be possible to use a tiddler tagged $:/tags/AboveStory or $:/tags/BelowStory to create a header or footer that provides a bootstrap for getting started again if you close the last tiddler?

[tobibeer]

Would it be possible to use a tiddler tagged $:/tags/AboveStory or $:/tags/BelowStory to create a header or footer that provides a bootstrap for getting started again if you close the last tiddler?

Sure, that's a workaround, but I would call it "$:/tags/EmptyStory". The other two seem to cater for something else: precisely what #1421 would cover.

As a sidenote, with the growing list of system tags, I really think they should not be top of the list when adding tags... as they have little to nothing to do with content.

Especially when I looked at that russian store, without a solution like the one proposed here, a visitor did pretty much look at an empty page, which is why he modified the navigator code so as to not close a tiddler. On the other hand, the close button could be removed, which surely seems advisable over him modifying navigator.js.

[Jermolene]

Sure, that's a workaround, but I would call it "$:/tags/EmptyStory".

There is the emptyMessage attribute of the list widget that could be used to display custom content in case the story river is empty. The content wouldn't be displayed as a tiddler (there'd be no toolbar buttons etc.). So, one possibility is to update the list widget for the main story river to read an empty message from $:/config/EmptyStoryMessage. We should also expose it in control panel.

As a sidenote, with the growing list of system tags, I really think they should not be top of the list when adding tags... as they have little to nothing to do with content.

I agree, but let's discuss elsewhere. Please open a ticket if there isn't one already about the edit mode new tag dropdown.

Especially when I looked at that russian store, without a solution like the one proposed here, a visitor did pretty much look at an empty page, which is why he modified the navigator code so as to not close a tiddler

One can use CSS to position the beforeStory content under the story river, so that it is only visible when the last tiddler is closed.

[tobibeer]

Ok, so I'll close this for now, perhaps post it somewhere as a possible solution, and we'll go with the empty message.