Closed Bug 11140 Opened 26 years ago Closed 26 years ago

Editor preview button has a confusing UI.

Categories

(Core :: DOM: Editor, enhancement, P3)

Product:
Core
Component:
DOM: Editor
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: CodeMachine, Assigned: cmanske)

Details

The "preview" button in the editor is confusing. Does the button text mean it's in preview mode? Will put it in preview mode? These sorts of buttons are confusing at first to novices and experts alike. Interestingly enough, the icon inconsistently doesn't change last time I looked, which would make it interesting to differentiate in icon-only mode. Anyway, here are some suggested solutions: (a) Put "In" or "Go" out the front of the text. This doesn't really solve the icon problem of not showing whether its "current state" or "move to state" totally though, but there is a precedent for this in 4.x - the security button on the task bar, which uses current state. (b) Turn "Preview" into the button with state, like the bold button. It is easy to understand pressed means preview is on and up means it is off. True, this doesn't say "Edit" when you can edit, but then you should expect that you can usually edit in an editor anyway. This would prevent the button from resizing, which doesn't look the best - it also causes reflows. Click the bold button up and down - on my system it keeps up with me, but the Preview button doesn't, I guess due to reflows. I also think depressed buttons look nicer.
Status: NEW → ASSIGNED
Target Milestone: M12
This "preview" thing was an quick hack, not intended to be the final feature. I know it should show state. We need to discuss this in the newsgroup. Your analysis is good - I invite you to copy it and start a discussion at netscape.public.mozilla.editor and CC to ...mozilla.ui as well. Yes, it does not toggle as fast as using bold, but it is reflowing the entire document. We should figure out how to put up a wait cursor when that happens? Note that you will be able to edit in either mode, its just a display thing, like showing end-of-paragraph marks in word processors.
If you had a bold button, there wouldn't be a reflow problem. Will raise the issue.
It looks like discussion has completed on this. Consensus was that tabs would be the best idea for more than 2 editing modes. However, we're likely to have only 2. Consensus was not reached, but most people felt tabs were best for 2 modes. Does XUL support tabbed panes? Is it easy to change between tabbed panes and listboxes for implementing this? As simple as changing the XUL? No consensus was reached over the best names for the two modes, the only consensus being that all suggested names were suboptimal or too long to use. It was further suggested that a source editor would be another tab. A Mozillazine post about the DOM viewer suggested there could also be a "DOM Editor", and I imagine that would be another tab. This could go further with more modes, in which case a drop-down box might become the best solution as opposed to tabs. The true "preview" with Javascript enabled might be another tab, or it might spawn navigator as per NN4. This would mean that there's one tab that's non-editable, whereas the others are, but it would make it quicker to change. Even in this case, I suggest a way of getting NN4 preview in navigator window, since there was some dissent that people might want to do it this way.
This will probably have to wait until after Beta1.
Source Editor = Bug #14526, DOM Editor = Bug #14527
Bug #14968 and bug #12111 together suggest a similar thing for the browser.
I have implemented a "tab" like interface at the bottom of the content screen for switching between the "Normal Editing" and "Edit with Browser Layout" modes. This will be checked in soon. So adding more tabs for other views is easy.
The current button seems to have regressed so that it gets smaller each click.
This seems to be in now and working well. One suggestion though, remember the person who complained about the concept of WYSIWYG mode implying it would always look like that? Well maybe "Mozilla Layout" would be better than "Browser Layout", since it still sounds like that. I didn't realise you'd put the tabs where you have, and as a consequence you have plenty of room for more words. BTW, you may want to consider making it possible to hide these tabs, like with the sidebar and toolbars on the browser, which can be both collapsed and totally hidden (from the View menu).
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
The exact wording to use is still under discussion. I don't think using "mozilla" conveys anything. I didn't make this a collapsable toolbar on purpose since it is very thin as it is. Also, I think after collapsing, it would put the collapsed widget up at the top with the other bars, which would be confusing. If it doesn't, and leaves a thin bar at the bottom, we don't gain enough extra pixels to be worth supporting the collapse, in my opinion.
Yeah I kind of realised that, but you would still want the option to remove it entirely.
Status: RESOLVED → VERIFIED
verified in 10/12 build.
You need to log in before you can comment on or make changes to this bug.