[Concept + demo] ViewFields - front end fields

[Mat]

Dear all,

Problem
Unsurprisingly, a tiddlers content contains segments that are treated differently from one another; the user must explicitly type in which formatting to use or he must for a segment or manually define the button or other widget or he must type in to define a macro and type the invocation for it, including the correct parameters and syntax etc.

I'm stating the obvious here of course - this is what TW is much about. But given the many special keywords a user must apply - and know about - and know how to apply - this is part of the steep learning curve and threshold to TW. It is also a time consmer every time you must look up and type in the same keywords or parameter names again.

Simplification
The idea in ViewFields is to use fields - in view mode - as abstract boxes to encapsulate the content. Then the user simply selects the type of magic to apply, from a dropdown. The selected type could be for example; "apply table CSS" or perhaps even "convert the text into a table" to begin with. Or, if the selection is made before filling in the content, a default content could show up showing the attributes or the macro parameter list that is to be filled in, for that selected type. The exact implementations for these types would probably be dealt with on a per-case basis.

In the demo, I'm also presenting what I thing is the simplest way to directly edit such view mode fields. That is a separate solution but merges well.

What I'm asking from you
I should first note that I don't have (even 1/10th of) the skills to implement this. I present it and hope others will find it interesting enough so it might eventually become something. (That said, I did just install the demo in some of my own TWs, mostly because of the direct editing feature.)

I'm asking you what is good/bad with the concept. Why would it not work? Should it not be using fields but perhaps instead "magic boxes" that segments of the content is encapsulated with that shows a dropdown from which to select the magic that should apply? Overall I feel fields have much more potential to the average user but they are unnecessarily left in edit view as if they were more complicated than they are (...I think ;-)

Regardless, here is the demo for ViewFields.


<:-)
TWaddling since 1915 (...no, still no update to that site for a few months)


P.S Thank you @Felix for some valuable input that made the demo understandable at all.

[Tobias Beer]

Hi Mat,

Thanks a lot for the demo.

I quite like the idea to be able:

• to show (certain) tiddler fields directly in the view-template
  
• to also edit (certain) tiddler fields directly in the view-template
  

What I do not want:

• additional ui (your buttons to the right)
• it would be enough for me if
• CTRL+hover highlighted the field and
• CTRL+click would enter into edit-mode for the field
• an on-hover toolbar may also be ok, e.g. shown on CTRL+hover
• to automagically enter edit-mode for a field simply by hovering
• I would find this highly distracting

What I think is needed:

• it would be a show-stopper for me if all fields were displayed by default
  => so, first of all, we need: ways to define view-template fields:
• at the tiddler, e.g. in a field called view-fields
  
• the sequence defines the sequence fields are displayed
• view-fields for which no global config exists (see below) are always shown before any globally configured ones
• otherwise the global sequence defines the sequence
• globally, e.g. titles tagging to $:/tags/Fields
• I think I've been hinting at a need to globally configure fields for a loooong time
• anyway, each field-config would specify (some of) these fields:
• text
  the field title => mandatory
• inline-edit
  to allow inline editing;
  needs to be set to anything other than undefined / empty string
• view-template
  defines a template for how to view the content
• edit-template
  specifies a template for how to edit the content
• label
  a label to show for the field instead of the field-name
  specify the label to be displayed
• filter
  a filter expression specifying for which matching tiddlers the field is shown
• show-empty
  whether or not to always display the field even if undefined / empty
• manual
  exposes all the above configuration but won't display the field unless manually listed at a tiddler's view-fields field
  needs to be set to anything but undefined / empty string
• the list field for $:/tags/Fields specifies the sequence of globally shown fields
• by default, only those fields that exist for a tiddler would be displayed
  

Best wishes,

Tobias.

[Jeremy Ruston]

Hi Mat

A very interesting experiment, nicely done.

I think it touches again on the tension between bundling related information into fields of a single tiddler, or putting it into separate tiddlers that are threaded together. We need more experimentation and experience to understand what works best in different contexts.

Best wishes

Jeremy

On 4 Jan 2016, at 14:14, Tobias Beer <beert...@gmail.com> wrote:

Hi Mat,

I quite like the idea to be able:

• to show (certain) tiddler fields directly in the view-template
  
• to also edit (certain) tiddler fields directly in the view-template
  

What I do not want:

• additional ui (your buttons to the right)

• it would be enough for me to CTRL+click a view-template field

• an on-hover toolbar may also be ok, e.g. shown on CTRL+hover

• to automagically enter edit-mode for a field simply by hovering
• I would find this highly distracting

What I think is needed:

• it would be a show-stopper for me if all fields were displayed by default
  => so, first of all, we need:
  
• ways to define view-template fields:
  

• at the tiddler, e.g. in a field called view-fields
  
• the sequence defines the sequence fields are displayed

• e.g. titles tagging to $:/tags/ViewField, specifying the field title in their text
• the list field for $:/tags/ViewField specifies the sequence

Best wishes,

Tobias.

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/15a903cf-661c-4f2f-84fa-9d549c252aa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mat]

Tobias - thanks for input!

Yes, in discussing this, I think it is wise to separate the discussions into "fields in viewmode" and the "UI".

What I do not want:

additional ui (your buttons to the right)

• [...]
  

 

Agree, the buttons to the right should definitely not be displayed like that by default - but I did imagine a faint outlining border to show when hovering the field content and the actual buttons and editor to show only when hovering the buttons. But to use CTRL is a nice idea. I personally like the immediate access to edit but that's a separate issue.

What I think is needed:

• it would be a show-stopper for me if all fields were displayed by default
  

Agreed 100%

 

• => so, first of all, we need: ways to define view-template fields:
• at the tiddler, e.g. in a field called view-fields
  
• the sequence defines the sequence fields are displayed
• view-fields for which no global config exists (see below) are always shown before any globally configured ones
• otherwise the global sequence defines the sequence

(I'd much rather have a dropdown that automatically lists the available fields with a checkbox for the ones to be viewed and some arrow up/down next to each to sequence them. I really dislike the manully typed list fields we have now, including list-before/after. But OK, it's just a UI matter and could be fixed separately.)

• globally, e.g. titles tagging to

• $:/tags/Fields
  [...]
  

I don't understand but I really want to. Which tiddlers are to be tagged such? Is it perhaps a tiddler that is to represent a (single) field into which you make the "settings" for that field? (That does sound like a good idea! Might one refer to those listed aspects as "field attributes" in that case?)

I'm very happy to understand you also feel that fields have a lot more potential than what we're currently doing with them.

Do you have any thoughts on problems with the concept of using fields as containers and select a "type" to apply some function to the content?

Thanks!

<:-)

[Mat]

Jeremy - thanks for the compliment!

I think it touches again on the tension between bundling related information into fields of a single tiddler, or putting it into separate tiddlers that are threaded together.

Do you see any unavoidable problems that would make the idea to use fields as "functions" and the content as it's argument? Does it make sense at all to make a kind of "box" that has a selected widget or other "function" associated with it so the field content is fed into the widget?

Could those problems be better solved by instead - as you say - "threading" multiple tiddlers, i.e apply the functions to the content in that way? I have used fields for the concept because the're kind of there already. The content is really the content that the user would put in only one tiddler - but he would then have to apply all kinds of widgets and formatting in the usual and more manual way. (For example HelloThere on tiddlywiki.com clearly has several "sections" in it - but splitting it up into several tiddlers is probably overkill.)

Thanx

<:-)