[TW5] GUI Theme Tweaks Size Settings

[Mat]

Bla bla bla ... Controlpanel > Appearence > Size settings...bla bla ... not perfected yet ...bla... ideas are welcome.

<:-)

TWaddle.tiddlyspot

[Jed Carty]

This looks very good.

I have been trying to come up with a good way to have an extended control panel that doesn't result in either a gigantic single list that is hard to navigate or dozens of tabs that are hard to navigate. I think that using something like the mobile menus I made may give a decent way to navigate through the options, or possibly using the modified version I made. This would let you add configuration options to the control panel using tags without having to create more tabs, and it could be made searchable using a few different methods. I am getting kind of burnt out on my other projects at the moment so I will try to throw together a quick demo later today.

When using the sliders to set values can you limit the set of options? Like use the slider to pick between 5, 10, 12, 14 etc., instead of allowing every point between? That would let you prevent having to reload the wiki because you set the sizes to zero. That was the first thing I did when trying out the demo.

[Jed Carty]

Here is a quick demo of what I am talking about. I was going to use your sliders to set the values but I can't figure out how to make them work. If I can make the I would like to have one of the sub-menus (called 'Page Layout' or something similar) be the adjustments you have for tiddler/sidebar positioning and move the font options into an appropriate sub-menu of their own. I think that instead of having the text input like I have now, each option should be a slider with a select widget that lets you pick the desired unit and have the options on the slider adjust to be appropriate for the selected unit (so 1-100 when using %, vh or vw, some range for em, and another range for px and so on).

I think that using what you have made will let us make something to allow users to make fine adjustments without requiring any knowledge of the inner workings of tiddlywiki or css.

[Eric Shulman]

On Tuesday, June 2, 2015 at 12:38:31 PM UTC-7, Jed Carty wrote:

that lets you pick the desired unit and have the options on the slider adjust to be appropriate for the selected unit (so 1-100 when using %, vh or vw, some range for em, and another range for px and so on).

The "range" HTML input control accepts 3 special parameters: min, max, and step -- with the obvious meanings.

In TW5, you can currently use

   <$edit-text tag="input" type="range" tiddler="..." field="..."/>

to create a range input control.

However, <$edit-text> does not yet support use of min, max or step params, so the range input control you get uses the defaults (min=0, max=100, step=1).

I have modified my own copy of the core's edit-text.js widget definition to add support for those params.  Jeremy has already indicated that he will also add that handling to the standard core code, so that the full features of the range control can be used.  I will be submitting a pull request shortly.

Until then, you are stuck with just 0-100 for range controls.

 

enjoy,

-e

Eric Shulman

ELS Design Studios

TiddlyTools - "Small Tools for Big Ideas!"

InsideTiddlyWiki: The Missing Manuals

YOUR DONATIONS ARE VERY IMPORTANT!

HELP ME TO HELP YOU - MAKE A CONTRIBUTION TO MY "TIP JAR"...

   http://TiddlyTools.github.com/fundraising.html#MakeADonation

Professional TiddlyWiki Consulting Services...

Analysis, Design, and Custom Solutions:

   http://www.TiddlyTools.com/#Contact

[Mat]

@Jed

----------------------

Edit: I realized what is missing in your demo, using the sliders:

You must also fill in the Size fields in Ctrlpanel>Appearance>Themetweaks to read the values that are stored in $:/.ThemeTweakSizes

The Stylesheets are reading the values that are specified in specific tiddlers. These tiddlers are what are set in the (standard) Theme Tweaks, via transclusion. So what you're doing now is instead to "forward transclude" one more step, to where the slider values are stored.

I've updated the tiddler on TWaddle to state this.

I am aware that this, obviously, means the whole "user friendliness" point is missing. This is why it is still just a proof-of-concept and not a plugin. However, My hope is that it can be made to work 

_____________

You've got some seriously interesting stuff there!!! Access to maximum control while simultaneously not overwhelming the user does in deed seem a tricky problem. But I reason that if those major web search engines can make sense out of zillions of webpages, then surely we'll figure something out for a few hundred tweaks.

First of all, I think locating a setting is one thing and presenting it is another. Not that you've contradicted this, I'm just sayin', because I think we can deal with the issues separately. 

For locating something as abstract as, for instance, some particular CSS setting, I think the solution is to attach "all imaginable" search terms to it. Your demo seems to indicate you reason like this too. When we eventually federate, it would be really useful to let "the world" attach e.g tags to settings for quick search localization. However (and this problem keeps coming up for me) tags in their current implementation or presentation are not very good for search as you're limited to very few tags per tiddler or it simply looks bad visually. They're probably better for categorization than as search terms. As you may know, I and others have brought up the issue many times ("tag types" and similar terms, as well as hiding tags). Tobias made a solution with "keywords" - maybe it is useful for the Settings context we're discussing here? For Settings it is probably not necessary that the user actually sees all meta-search-data so might be useful.

Like you indicate with your demo, I think tagging (or comparable) would be a key aspect in this. 

Your modified version that allows searching tags within different contexts should be very useful, particularly as it could allow tagging (or similar) more freely. If users are to be able allowed to tag, then we can expect tags like "important!" or "good" and to have such results appear in context should be very useful.

Do you know of the old Tagsplorer macro? It feels related or at least relevant to check out. Unfortunately the hosting site for it is down, but I found this discussion.

I really like the mobile menus thinking! Brilliant to let the irrelevant menu items disappear. Did @Jeremy see this - as option to his system tiddler explorer, which he is not happy with?

 

If I can make the I would like to have one of the sub-menus (called 'Page Layout' or something similar) be the adjustments you have for tiddler/sidebar positioning and move the font options into an appropriate sub-menu of their own.

The font options are a bit problematic because when you change them, the whole page can change which makes the fontsliders move. This is why I put them in a fixed box. If we get the min/max/step working, then this might be less problematic.

 

I think that instead of having the text input like I have now, each option should be a slider with a select widget that lets you pick the desired unit and have the options on the slider adjust to be appropriate for the selected unit (so 1-100 when using %, vh or vw, some range for em, and another range for px and so on).

I agree that different units are appropropriate depending on which setting, but to have a select widget seems more cluttery than useful to me. 

Unless you mean another idea I've been thinking of: To have one single slider, for which you select setting, perhaps from a select widget. A "central slider" to which you bring whatever it is you want set. Then, maybe, a unit selector might make sense unless it is not already coded as meta data to the thing you want to set.

 

I think that using what you have made will let us make something to allow users to make fine adjustments without requiring any knowledge of the inner workings of tiddlywiki or css. 

Exactly! The unnecessary knowledge and information should be cut out. The user should be able to focus on working with TW, not on TW. Content, not TW per se. (Unless he wants to, like most guys here do.) I like range sliders because they don't force you to know arbitrary "numbers of pixels", or even "pixels" for that matter. 

Ok, I'm going off on tangents as usual but I'm getting excited from your demos. Please continue to share your thoughts and tell me if you think I can help out.

<:-)

[Mat]

@Jed - I don't know of you read these messages via mail, in which case I've understood that edits are not reflected so please read the post above this one as it is currently.

[Jed Carty]

You are right about the clutter. It may not be too bad if it is used as a one time configuration that is then left alone, but if the configuration is going to be changed regularly it will be way too much clutter. I added a lot to the demo.

Because Eric said to not use his I threw together a simple range widget that lets you set min, max and step. It is just thrown together so it isn't elegant but it works for the demo which highlights the problem you mentioned when using them. That is even if I set a value to 100px, then switch the unit to em instead of pix it results in a horrible mess.

The list of css properties I have in the demo wiki lists the input types taken by each one as number, text or color. Setting a color picker for each color field isn't a bad idea but a generic numeric slider is way too easy to mess up the way it is now. I could add some more data tiddlers that list min and max values for properties that take numeric inputs, but that would lead to some other annoying problems so I am not going to bother with that for now.

Also I completely agree that the solution to how hard finding a particular item is would be to tag it with all related tags, this is what I was trying to allow with the modified menu version I made. I am not sure how well it works with a large number of entries yet, but it is start.

I don't know if Jeremy has seen it yet or not, I was going to try demoing it at the last hangout but I had to leave early.