Looking for a standard solution and UI to hide stuff in TW

My proposal to relocate the type field in edit view, mostly to “declutter” the UI, triggered a comment by fellow @saqimtiaz where he said:

From a UX perspective I would be much more inclined to support the affordance to hide less commonly used UI elements until needed, with what is less commonly used being configurable by the user.

While this point doesn’t necessarily exclude my proposal, I have to agree that also hiding it all together would be even better! But it would only be good if such configuration is…

  1. locally located - i.e accessed directly where the user’s at, i.e from within the edit view (not via e.g the Controlpanel or inside a tabs in the tiddler info)
  2. locally applied - it only applies to the current tiddler
  3. self explanatory - it is obvious how to use it (or gives direct feedback)

In fact, there are several things I would like to hide from default edit view:

  • the type field
  • the custom fields area
  • some of the editor tool buttons
  • …sometimes the whole editor button toolbar

Imagine if users by default were faced by something like this:



…presuming that it was obvious there’s more stuff and that this is easily brought forth. So my question here is:

How can hidden information fulfil the criteria #1-3 here above?

I’m hoping for some generic mechanism and UI. A standard solution that we can use ubiquitously.

The “more button” seems like a pretty obvious go to and that we already use. I guess they always use revealwidgets (right?) In view mode it is used in the tiddler toolbar and optionally as the “fold tiddler” button. In edit view it is seen in several places; the tags, type, and custom fields dropdown and the editor tools more button.

But how should additional more buttons for hidden stuff be presented? The above illustration would not be very pretty if it had more buttons seen everywhere. Maybe “show on hover”?

And how should things be moved between the visible interface and the hiding area?

Thoughts?

I despise hidden interfaces. (Like things that only appear when you happen to hover over some unmarked area where the things are located.)

But I do love something that is subtly-visibly “collapsed”, so that I know it is there and I can expand it when I want. Well, there are certain things that I do want grabbing me by the jugular, so having the option to set a preference is nice.

Give me a button like for a details element, or a button like for reveal widgets, or a button to open the extras in a modal window. (well, option to open in a modal window; sometimes, a modal is nice to focus on something, other times not so much because the thing you’re looking at, you want to see the other stuff too.)

2 Likes

Right. So there has to be a balance. In the current edit view interface, a lot is (fortunately) hidden. It would be information overload otherwise. But, as implied, I still think it should be cleaner.

I usually really dislike modals but this does give me an idea; What if a modal showed a visual replica of the tiddler with all the hidden elements I mention visible and a lot of toggle checkboxes on them, or perhaps prettier, each element is a button and all “active” elements are in some color and all hidden elements in another and you toggle by clicking. Pretty cool and intuitive.

I.e then you’d only have one “settings” button to open this modal.

I think I like it (whether or not what I’m picturing in my mind matches what you describe, who knows?)

I like it better if the various “sections” can be collapsed and expanded. (Yes, I love the HTML details element. Wouldn’t be able to function without it. Helps me focus on the “section” I really need to focus on, while making multiple sections simultaneously available to me when I need to cross-reference them (to see a bigger picture/context when the smaller one doesn’t quite make sense.)

KEEP IN MIND: I’ve seen some older web browsers not support the details element, but support the TW reveal widget A-1.

As I stated in the conversation that proceeded this, I do believe just as important as being able “hide or conceal elements” on the edit (and view template) is the ability to “reorder them”. The moving the type field is just a single case of this reordering.

However this reordering will be far more useful If it can be both global and permit a conditional or local override of the show/hide and order.

  • The first step is to realise these alternatives in an alternative Story Tiddler cascade or similar “optional” solution. That is any new behaviour can be installed and selected
  • The second step is once tested it could be proposed as either;
    • An option available in the core
    • An option that is the default
    • Replace the default in the core

Like the Six million dollar man “we have the technology” to build this, we just need to deal with some details and ideally do so in a collaboration, because there are few choices that need “socialisation”.

  • I must say trying to pair with even one person in a collaboration for a shared goal is proving difficult in this community for me, except in a long thread in an ad hoc way.
  • Thus I propose a collaboration, starting with a Zoom session, I am in the +11 UTC time zone.
  • We really must develop this collaborative process in the community.

The Technology;

  • I think we could consider enhancing the current fold/unfold mechanism to achieve both the show/hide but also the ordering.
  • This can initially be done inside a layout or Story Tiddler Cascade.
1 Like

@TW_Tones , your post goes way off from what I am asking about and looking for. May I please ask that you move your post into a new thread instead?

Mat I can, but with respect I want it known that I think these should be part of the same solution because they are intimately related and the solution in one will impact the other. So moving it out is disconnecting it.

  • It directly relates to UI to Hide stuff
  • I suggest a possible approach to this “enhancing the current fold/unfold mechanism”
  • And suggest reordering should be part of such a redesign or they will clash
  • I also point out what you would like can be implemented through a story cascade, or layout.

Perhaps this is the most related reply I have ever done, so to ask me to move it away is confusing.

Tones, so instead of my OP about hiding local stuff, you want to hide and reorder and do it locally and globally. Well, while I agree with most of your greater ambition on the issue, the chances of getting the things you propose implemented into the core is zero. It is way too undefined and too everything. I base this on 15 years experience from having comparably wild ideas rejected or ignored (and probably for good reasons). I believe my OP is worthwhile and has a speck of a chance because it is pretty well defined… or at least it was before Saq objected to my type-field-relocation-proposal and instead “prefer hiding less commonly used elements until needed” - so that is what this thread is about.

In your own thread, do feel free to link to this thread though :slight_smile:

1 Like

One method that just occurred to me is to reproduce the Fold Bar or Buttons for the edit view. We would enhance the fold mechanism to also respond to a config tiddler such that it is an option.

  • For example you can choose by default to have to use the unfold button to see the $:/core/ui/EditTemplate/type and $:/core/ui/EditTemplate/fields which are hidden otherwise.
  • When unfolding these other elements in the editor it will be stored in a state tiddler for that tiddler.

What do you think @twMat ?

If I understand you right, you mean to make the tiddler fold/unfold button have several states, where one is to make the tiddler show a custom subset of template items - right?

But that assumes you want the same subset every time though (right?) so what is needed is a smooth way to make items be part of the subset or removed.

I would think drag’n dropping is the most intuitive way to move items between two places. I wonder if it is possible to, say, open a dropdown in the toolbar (comparable to the “more” button) and grab an item and drop it onto the tiddler so it appears there?

…and vice versa, to somehow grab, say, the type field and pull it up into/onto a button in the tiddler toolbar and drop it there - so it disappears from the tiddlers view and instead appears in the buttons list dropdown.

…continued.

Here’s a pretty cool idea; A tiddler toolbar button that not only opens a dropdown but also sets the tiddler in a state to modify its layout.

  • Actually that is more like my bigger idea, you suggested we move to another thread. It solves the OT but adds more value.

The tiddler fold state would be basically to;

  • Also include the fold/unfold button on the edit view. (with a different state tiddler prefix from the view templates fold)
  • Basically you would nominate the fold state, to hide the “type” and “add/edit fields” content. Thus in an unfolded state it would look like the normal editor, in a folded state it would look like your proposed view in the OT.

However like you, I would prefer it to be little less binary, and having the ability to have more than one subset of show hide.

  • Actually we can bypass this problem by using the cascades. This is a “permitted” hack, no core changes, You only need a package or plugin.

Warning what follows in a comprehensive response that not only suggests “the what” but “the how”, and is I believe something I can make. In fact I have already an example under development.

  • yes, It is with a little more work we can do this.
  • my approach is however compatible with your idea and may also facilitate reordering of the items.
  • a drag and drop method can be added.

My current “extended vision”.

  • Imagine (only when in a design smode perhaps), with a click all the items tagged $:/tags/EditTemplate would be saved into a list field on the current tiddler
    • Let us call it the “EditTemplate-listitems” field.
  • If the “EditTemplate-listitems” field exists it will be used instead of the $:/tags/EditTemplate items,
    • to only display those elements listed, and in the order they are given. The existence of this field can trigger a different “Story Tiddler Cascade”, an alternative Edit Template which can do this extra handling.
  • The drop down you suggest could look like a “tag pill dropdown” with a list of all potential edit template items, a check box to show/hide each element in this tiddler (ie add remove from edit template view) and also a drag and drop the order, just as the tag pill does.

The advantages of this approach is;

  • Optionally what ever the custom edit template, the fold/unfold button in edit mode would toggle the standard editor and the custom view.
  • No core change just an extra cascade
  • New tiddlers can be made from a template with a pre-set “EditTemplate-listitems” field
  • You can add the field to configure any tiddler independently. Including adding items not already tagged $:/tags/EditTemplate
  • You can also change the order of the items on the template with out affecting any other tiddler.
  • This can be implemented on the view template as well, with a ViewTemplate-list field, something I want, for other reasons.

I have a way to extend this further, but that can be discussed later. It would allow

  • A variable to be set that is used instead of a hard coded list field.
    • This would allow a truly global option.
  • Use a similar list to rule in or out nominated additional fields for edit, and their order, in the edit view; eg edit the description and caption fields, this would be the fields-list.
    • I would use an additional item tagged tagged $:/tags/EditTemplate that handled the “edit” field-list, that you could choose to include/exclude in the EditTemplate-listitems field.
    • The fields-list can also be used on the view template.

Not sure if I should start a new thread, but what I’m about to ask seems related. This post is very technical

I like the idea of having the option to simplify the user interface, when needed. When I have time I’ll be playing with minimising/hiding the Tools and More tabs, as I’ve seen in some TW website examples — this will suit some shared projects.

Question: re. the editor toolbar buttons. Once I realised that anything you disable in the control panel appears in the more dropdown, I disabled Bold, Italic, Underline, and others. Unexpected behaviour resulted. (I do like the convenience of “more” to declutter.)

When the buttons are present, I’m able to use standard keyboard shortcuts, HOWEVER when disabled the shortcuts don’t work. If this isn’t a bug, what’s the logic?

1 Like

Have you looked at these on tiddlywiki.com. It suggests the keyboard widget is for text fields and the ’ Keyboard Shortcut Tiddler’s for global.

1 Like

I think a list of elements to hide may be the best approach if we dont need to allow the order to be changed.

Then a seperate tool to reorder would make use of a sortby field and you only need add elements you want to appear first.

Doesn’t work for mobile.

1 Like

I have used the cascade mechanism to use an alternate $:/core/ui/EditTemplate if one of two fields exist. With very few changes;

  • it now will selectively hide elements in the edit template like the OT
  • It also allows you to set a custom sort order for all elements within the Edit template
  • Since currently this acts on the current tiddler I have placed this configuration behind the info button.

It is trivial to extend this to the View Template where you could show/hide/reorder items such as Projectify, streams and other add on elements displayed via the view template.

  • This is also related to the OT given its broad “Title” Looking for a standard solution and UI to hide stuff in TW

I am working to see if there is an integrated way to have hidden and sortable elements set conditionally or globally without the current tiddler having local fields set.

@twMat are you interested in hiding other elements in the UI outside of the view and Edit templates?

@TW_Tones

There are two overarching problems here:

  1. I made a mistake in requesting a “solution” to hide stuff. This is too complex and I should limit it to only requesting ideas for a standard UI to hide stuff. Only after defining “what is wanted” can implementatins be meaningfully discussed. I’m still at the first stage - the UI - but you evidently have a clearer vision so you can deal with the second stage.

  2. Underlying the OP there is, indeed, a bigger vision for an improved UI for native TW. As such, it is typically a waste of time for people like me (and you?) to try to come up with the technical implementation because it just won’t live up to the standards required for the core. Instead, I find the best way to communicate my ideas is to make clear mockups, typically just illustrations, sometime rough prototypes.

So I’m laying this thread to rest but will possibly repost the OP in a new thread but according to what I just said.

Thats fine, but I am confident I will have a good solution soon. It fact I already have it working. Keep in mind the introduction of the cascades empowers us all. We can avoid core changes altogether but also demonstrate how the core could change, of course input from those with deeper knowledge can help refine such a solution.

I may start a new thred and link there.

Thanks for your understanding. I’m curious to see what you’ve come up with, and I must confess I don’t quite understand cascades yet but have only investigated it briefly.