Closed twMat closed 7 years ago
I think "Appearence" settings and "Behavour" settings should not be mixed.
As a user I don't care about which story view is set, if I want to change the "click on link behaviour". I personally would never search for this setting in "Appearance"
... on the other hand. I think the Control panel grouping could be improved. All top level settings use tabs in the details area. Except "Settings"
Hola @twMat
IMO it should be placed under tab Storyview,
I agree with @pmario here that behaviour and appearance ideally should be separated.
but only appear there if a relevant storyview is selected.
You are right here of course! There are some more options that are dependent on each other, e.g.
We could (1) use the reveal widget or list widget to show hide configs that depend on other config or (2) could add an info text when a config has an affect (which would bloat the wiki again because it needs to be translated), or (3) just leave everything as it is now because the user will probably not touch options he is not interested in and changing them does no harm anyways when they do not have an effect...
... on the other hand. I think the Control panel grouping could be improved. All top level settings use tabs in the details area. Except "Settings"
I agree. There is already a discussion going on about this issue: https://github.com/Jermolene/TiddlyWiki5/issues/1689.
but only appear there if a relevant storyview is selected.
You are right here of course! There are some more options that are dependent on each other, e.g.
Invisible settings is really bad, and will cause support request in the group. eg: "I can't change this setting" our answer: "you need to switch to standard mode first" reply: "wtf, I use zooming mode only" ...
You can add more information, that is context sensitive. So eg: This setting has effect only if ... but don't make global settings invisible.
reply: "wtf, I use zooming mode only" ...
Hehe! However, e.g "open new tiddler below current one" in zooming mode makes no sense. BUT there could be confusion in that people may not understand what others are talking about ("I don't see any settings there!?") - So, a better alternative could be grayed out settings, i.e that cannot be used, and possibly a note saying it's not applicable for this story view.
So, a better alternative could be grayed out settings, i.e that cannot be used, and possibly a note saying it's not applicable for this story view.
IMO inaccessibility is as bad as invisibility for global settings. .. What you are suggesting here is, that every view mode, needs an additional configuration, if any configuration setting is disabled.
So we need an accessibility tiddler for every single parameter in the Control Panel. I personally don't like this idea.
@twMat @pmario I'm also against user interface elements that appear and disappear based on the current configuration. As @pmario says, it's an awful lot of engineering, and it makes support and documentation a bit of a nightmare.
But I do like the idea of re-organising the control panel (as discussed in #1689), and the specific suggestion here is interesting - it implies an organisation based on elements of the screen: sidebars, story, tiddlers, appearance. There would be an opportunity at the top of each tab to have some text explaining what a sidebar is, which might improve learnability. It would be interesting to work it through and see how it looks.
I have to agree with @pmario with this. Hiding settings is a bad idea. It's something that I'm also discussing at work. Hidden options produces lack of knowledge about what is available
... Hidden options produces lack of knowledge about what is available
exactly.
But think of the joy people will get when they do eventually stumble over the hidden goodies!!!
No? Okay, okay ;-) But on a serious note: What should then be done to prevent users from thinking something is wrong because nothing is happening when they set some things?
But I must confess I don't understand what would make it so complex (likely, of course, because I'm not a coder). The few story-view depending settings that exist could have, say, a little local "blacklist" of story views. By default the setting font-color is normal black. If a storyview is active and in the settings local the blacklist, the font-color is gray (or transcluded icon showing, etc)
Or is this an example of the nightmares you refer to? ( @pmario @Jermolene )
AFAICT it would also be simple for plugins or other user defined settings etc to reuse this method.
No? Okay, okay ;-) But on a serious note: What should then be done to prevent users from thinking something is wrong because nothing is happening when they set some things?
Additional info with or near the setting.
Hi @twMat the technical matter of making bits of the control panel appear and disappear according to the prevailing story view isn't the issue. The problem is usability and documentation. It's disorientating to the user if they return to a place and it appears differently, without a means to determine why.
One could treat this similarly to validation: if a non-default setting is selected, and the current story view prevents the setting from being applied, then display a little red warning message alongside the UI element.
Perhaps "Story View" is better located under settings, as it's really not just a "how things look" item but rather "how things behave".
Perhaps "Story View" is better located under settings, as it's really not just a "how things look" item but rather "how things behave".
+1 !!!
I'm still interested in a redesign of the control panel. It's overgrown and needs pruning and reorganising.
I agree. Personally, I'd be in favor of only keeping the very essential bits in the default controlpanel, with an extended mode being...
I agree that internal link behavior seems out of place in the control panel. I also agree with a new stylized streamlined control panel. I see menu's everywhere turning into just the icons with the descriptions as the tool-tip and selected isn't a check-box. Instead, it's colored or darkened for selected. I also see input of text being hidden unless long pressed or right clicked and the functionality being replaced directly in the view with re-sizable drag and drag-able features.
On Sat, Sep 19, 2015 at 4:56 AM, Tobias Beer notifications@github.com wrote:
I agree. Personally, I'd be in favor of only keeping the very essential bits in the default controlpanel, with an extended mode being...
- most importantly, filterable
- a flat list, having collapsed sections, collapsible / expandable (one branch at a time)
- customization interfaces like color palettes perhaps being modal ui's rather than inline
— Reply to this email directly or view it on GitHub https://github.com/Jermolene/TiddlyWiki5/issues/1740#issuecomment-141655581 .
If anyone wants to experiment with Ctrlpanel layout, I made this and this some time ago for myself. While I don't remember my own intentions with it, I think they might be useful because they're setup with "dummy tiddlers" to represent the current Ctrlpanel tiddlers, so they are easy to manipulate without actually messing with the real Ctrlpanel.
@Jermolene ... label "discussion"
I'm closing this because the OP turned out to be a mere sub-question for a greater need for Ctrlpanel redesign, which is justified to be a separate issue.
IMO Tobias' points make sense so I'm reiterating them as a final remark:
[keep] the very essential bits in the default controlpanel, with an extended mode being...
- most importantly, filterable
- a flat list, having collapsed sections, collapsible / expandable (one branch at a time)
- customization interfaces like color palettes perhaps being modal ui's rather than inline
@felixhayashi's work on giving the user an option where tidders should popup in the story view, ref #1651 , was recently accepted into /preview Controlpanel>Settings. "Internal link opening behaviour"
IMO it should be placed under tab Storyview, but only appear there if a relevant storyview is selected.
It is definitely about how to display things in the storyview and it feels like a more intuitive place than "Settings".
Also, the label "Settings" (like a label "misc") is itself unclear considering how a Controlpanel all about settings. (For further on this, see also #1135 and #1169 )