What to do with eip-figure branch? PART 2
Document Actions
In a previous blog entry, several ideas were discussed regarding ways to incorporate the new "Enclose with <figure>" feature, and I've made mock-ups of the ideas. View these on Firefox (I can make 'em work in IE later):
- Regular text
- Small text
- Smaller explanatory text
- Link on <figure> provides tool tip
- A "help" link provides pop-up window on click
- Selecting box provides "Name" and "Caption" fields
I prefer having the checkbox open up the "Name" and "Caption" fields (as in 6) instead of making it a two-step process, but I don't have too much of a preference in terms of how to display the explanatory text (probably this is my preferred order: 4, 3, 2, 5, 1). Making it a one-step process also makes it taller, but my guess is that the confusion caused by the two-step process is greater than the confusion caused by the need to scroll for viewers with small screens.
Another source of confusion may be the fact that having the "Edit params" link opens up a new area in a different way than the "Enclose in &tl;figure>" checkbox does (link vs. checkbox). I don't know if one or the other is effective in conveying the idea that one is just hiding the area and the other is turning the area on/off.
Re: What to do with eip-figure branch? PART 2
Re: What to do with eip-figure branch? PART 2
Re: Re: What to do with eip-figure branch? PART 2
Re: What to do with eip-figure branch? PART 2
BTW one of her suggestions was to rename "Edit In Place" to "Tag Assitant Editor" (or some such) to let the user know up from that tags are where it is at in EiP/TAE. Including name and caption kind of blurs the line between a tag editor and something more higher level and functional.
Some of the reasons that we added higher level access to table and media tags was because those two tags were very challenging for the end users to get right. The end user should not have trouble adding a name or caption to their new figure, since it is a one step process.
Another consideration is that table can have names and captions (conditionally) and by allowing an editable enclosable figure in the same UI the end user could be confused.
Re: Re: What to do with eip-figure branch? PART 2
You're right that #6 is more WYSIWYG than TEA, but I assumed the point of calling it TEA was not to remove all WYSIWYG but instead lower expectations by reminding users that they should know that they'll still have to deal with tags. IMHO, we shouldn't be so concerned with making this so TEA that we eliminate anything WYSIWYG if that little piece of WYSIWYG buys us some clear and effective functionality.
As for table names and captions, Manpreet has already requested that they be specifically labeled "Table name" and "Table caption" to help avoid that confusion, but perhaps we should treat table names in the same way that we currently treat table captions, i.e., not put them in unless they were already manually inserted via full source editing.
Re: What to do with eip-figure branch? PART 2
Re: Re: What to do with eip-figure branch? PART 2
I suppose that we could also do #6 for adding figures, and then edit existing figures in the same way we were going to do it (clicking on the figure (w/o clicking on it's child media/table/code)), but I would think that having the one interface would be less confusing to users.
Of course, in this whole process I've forgotten about subfigures. Oops! :-)
