Seeking Advice For Designing Custom EditTemplates

, ,
#1

Would it be poor design to create a custom editTemplate that uses form elements for displaying the fields?

I want to redesign the editTemplate in a way where the name of the field is in the border like a fieldset element (along with some other tweaks later on), and considering that the editTemplate is basically a form for modifying the tiddler, started to wonder why it wasn’t used that way, and if maybe this was done to avoid confusion?

So, I started to make a POC, nothing functional, but just enough to give an idea of what I might want it to eventually look like, and added it below as reference.

i.e.

<style>
.test-field-class {
border: solid 1px <<color table-border>>;
}
.test-field-class legend {
padding: 0 1ch;
}
.test-field-class input.test-field-class  {
border: none;
width: 100%;
}
</style>

<form>
<fieldset class="test-field-class">
<legend>Title</legend>
{{!!title}} <i class="tc-muted"> {{!!draft.of}}</i>
</fieldset>

<fieldset class="test-field-class" style="width:;">
<legend>Status</legend>
{{!!status}} //(custom field I'm adding for todo imcomplete, etc.)//
</fieldset>

<fieldset class="test-field-class">
<legend>Tags</legend>
<span><$edit-text tiddler=<<currentTiddler>> field="placeholder" size="10" focus="no" focusSelectFromEnd="13" default="placeholder for add Tags input" /></span> <<tag>>
</fieldset>

<fieldset class="test-field-class">
<legend>Text Editor</legend>
<$transclude tiddler="$:/core/ui/EditTemplate/body/editor" mode="inline"/>
</fieldset>

<fieldset class="test-field-class">
<legend>Editor Preview</legend>
<$edit-text class="test-field-class" tiddler=<<currentTiddler>> field="placeholder" size="50" focus="no" focusSelectFromEnd="13" default="Just a placeholder for the preview-preview" />
</fieldset>
</form>
#2

The main problem is, that the field names are dynamic. So a semantic HTML input form would have 2 input fields with 2 labels.

1st label would be name or field name and the text input below.
2nd label would be value with the text input below.

The “finished” field form would have a completely different concept, than the input form. The field-name would become the label and the text below would be the value. IMO that’s not consistent.

The title input form would have a title label and a text-input, where the label is constant text. That’s a different form with a new concept.

So we already have 3 different form concepts. IMO that’s confusing for new users.

IMO this form would also use significantly more vertical space, than the current setup does. That’s the main reason why it is as it is atm.

Just some thoughts

#3

I’m nit quite sure I follow, why would there need to be a text input with the field name in addition to the 2nd label’s value input element? :thinking:

yes, though this is just because I wanted to relocate the draft.of text that feels haphazardly placed at the top of every tiddler.

That is fair, this is a plus for me whereas it would not be for others, since I am primarily using a mobile device.

Do you have any suggestions in how I could approach it differently? or do you think using fieldsets isn’t a worthwhile approach?

#4

There are two criteria you need to satisfy:

  1. Does it do the job?
      – I’m never satisfied by “form ( :wink: ) over function”
  2. Do you like it?
      – Someone else will, too.
1 Like
#5

Justin it is acceptable to do what you like.

For me the fieldset is about grouping fields, ie a set, together. So I would be inclined to group fields in one or more groups or as a lable in some cases. I would also put a space at the begining and end of the legend. Inputs like tags and select widgets stand alone to me and I dont need to clutter the page with additional visual infomration unless it adds value and meaning.

However if you have looked at the Field Editor cascade? This only works to customise the edit component and is used by the edit template to produce custom edits for a given field. It may make sence to try and reuse this mechanisium then build your form on top of that. Thus if you have more than one form the edit component need only be modified in one place.

#6

haha thanks, sometimes its good to be reminded that, especially when you work in corporate enviroments a bit too much :sweat_smile:

I ultimately plan to, but I do want to listen to the inputs from others who might have more experience to get more perspectives on what sort of challenges I may face doen the road.

I’ll need to take another look at it, but I’m pretty sure that is what I had modified in the past to make some fields into textareas (though Im not sure if was because I’m a bit shaky with regex or something else but getting other fields like color to work like default just broke lol)

I saw this thread earlier but I think I got sidetracked before checking it out, I’ll give it a quick read to see if I can contribute or find anything specifically handy :grin:

#7

What I wanted to point out is consistency. You can do what ever you want, but it should be consistent in some form.

For tw-com we get a lot of questions, when something is different to the standards. New users do not know, why it is different. So that raises questions and delays the users workflow. In the core inconsistencies are “baked in” because many function did organically grow, by user request. So some elements have the “new function” and some older elements don’t.

But if you have the chance to plan something from the beginning, with the knowledge you already have you should try to be consistent. It will safe time in the long run.

2 Likes