Closed Bug 56673 Opened 24 years ago Closed 15 years ago

UI for Image Map Editor needs clean up

Categories

(SeaMonkey :: Composer, defect)

Product:
SeaMonkey
Component:
Composer
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: kinger, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

Diff of new file sent by Brian King for Image Map bugs
12.87 KB, patch
Details | Diff | Splinter Review
Required change to use non-editorshell method, suggested change to use "html" as default filter
592 bytes, patch
Details | Diff | Splinter Review
Change to support just showing "All Files" filter in Composer Open files dialog
1.02 KB, patch
Details | Diff | Splinter Review 
cc Dan & Kathy to keep informed

The UI for the Image Map Editor is a bit of a mess.  For example:
- menu and top toolbars did not collapse
- vertical toolbar had grippy which is not needed
- vertical toolbar too wide
- ok/cancel buttons not centred
There are other issues.  I have fixes for some of these, and I'll clean up the
rest soon.
More information of the changes and fixes can be found at the URL for this bug:
http://www.clubi.ie/kings/brian/moz/imgmap/ImgMapUI.html

This bug is a good place to post suggestions and solutions for this dialog UI.
All comments welcome.
ASSIGNED = moi.  Does anyone know how to approach this one (as in design, 
check-ins ...) ??
Status: NEW → ASSIGNED
Paul--can you suggest someone to help Brian and Dan out on this bug?

Brian--if all else fails, you might want to solicit help on the editor newsgroup 
or in the ui newsgroup?

From the screenshots:

1.  Dialogs should never, *never*, have menus. See
    <http://developer.kde.org/documentation/standards/kde/style/basics/
badInterface.html>. All the things that are in the menus now should be turned
    into other controls, or removed altogether. (For example, why do you have
    Cut, Copy, and Paste in an image map editor??? I can't think what you'd need
    them for.)

2.  Similarly, dialogs should never have toolbars, whether collapsible or not.
    (Toolboxes are ok, as long as they're really for tools.)

3.  The toolbox buttons should have borders. As it is, for some pictures the
    tools could easily look like part of the picture.

4.  Just by looking, I can't tell why that `Contrast' button is there. It looks
    as if it would adjust the contrast of the actual picture inserted into the
    Web page, but I assume that is not the case. If it is just for adjusting
    the view of the graphic while you are editing the image map, then you
    probably want to change the icon to a magnifying glass with RGB stripes in
    the glass -- so the user assumes it is similar to the zoom in and zoom out
    buttons, in not actually changing the content of the image.

5.  The canvas should be a Photoshop-like gray-and-white checked pattern -- not
    white, which may make the border between the canvas and the background of
    a white image hard to find.

6.  I should be able edit an image map entirely using the keyboard. That means
    the following (some of which may be in a dialog of their own):
    * a listbox of areas, with `Add', `Delete', `Change ...', `Move Up', and
      `Move Down' buttons;
    * a popup menu to let me convert an area from one shape type to another (but
      if the area is changed from a polygon to something else, the polygon points
      should be remembered just in case I change it back, until I close the
      dialog);
    * text fields to enter the coordinates of the area;
    * a listbox (to the left of the coordinate fields) which is enabled if the
      area is a polygon, for showing which point of the polygon is being edited.

7.  The UI needs an audit to find things which need to be changed to make it
    comply with the W3C Authoring Tool Accessibility Guidelines. For example, you
    need to provide prominent UI for specifying the ACCESSKEY, ALT, TABINDEX, and
    TITLE attributes for each AREA -- and of course to change the actual order
    of the AREAs, which will determine the order in which they get read/shown by
    non-graphical browsers (such as Mozilla with images turned off, for example).

Further advice will have to wait until I can get as far into Mozilla as the image 
map editor without crashing. :-) Or, if you like I can give you a complete UI 
spec which you can gradually implement, using the current UI as a starting point.

Addressing Matthew's points, though Dan and others may be better qualified to 
answer these:

1.  Dialogs should never, *never*, have menus... (For example, why do you have
    Cut, Copy, and Paste in an image map editor??? I can't think what you'd need
    them for.)
2.  Similarly, dialogs should never have toolbars, whether collapsible or not.
    (Toolboxes are ok, as long as they're really for tools.)

Think of this as a separate editor as opposed to a dialog.  This is how it was 
originally designed and implemented, but in the context of the Mozilla Editor 
this may have to be changed.

3.  The toolbox buttons should have borders. As it is, for some pictures the
    tools could easily look like part of the picture.

Are you referring to the toolbar itself, or the buttons?  Shouldn't the latter 
only be the case onmouseover?

4.  Just by looking, I can't tell why that `Contrast' button is there...

There is talk of this going.  It is not needed.

5.  The canvas should be a Photoshop-like gray-and-white checked pattern -- not
    white, which may make the border between the canvas and the background of
    a white image hard to find.

Yes, it should be and it was.  What happened to it?  We'll look into it.

6.  I should be able edit an image map entirely using the keyboard...

Good point.  Is not this the case for all editing functionality, so as not to 
discrimate against non-mouse users?

7.  The UI needs an audit to find things which need to be changed to make it
    comply with the W3C Authoring Tool Accessibility Guidelines...

Yes, I'm sure you are correct here.

"Further advice will have to wait until I can get as far into Mozilla as the 
image map editor without crashing. :-) Or, if you like I can give you a complete 
UI spec which you can gradually implement, using the current UI as a starting 
point."

It was working and stable, but there may be regressions in recent builds.  A 
spec would be useful, but hold off until we get some further input.

Thanks.
In reply to Matthews post!

1) This is not really a dialog! It is a mini program, similar to the view source 
dialog. Cut, Copy, and Paste are fully functional and are used to duplicate 
areas or temporarily store them out of the way while working on something else. 
It is also a temporary fix to the order problem you suggested in #7 as the last 
thing created is always placed on the bottom.

2) see first section of #1

3) Agreed! I think this is the kind of thing Brian already has in the works.

4) The contrast button originally faded the image to make it easier to see the 
hot spots. It was also a toggle button so it would be easy to tell what it did. 
As of right now it doesn't work, so we may be forced to remove it altogether 
anyway.

5) It is already exactly like PhotoShop including the checkerboard pattern 
behind transparent images. If it's not working now it's do to a CSS problem.

6) I'd love for this to happen, but we can barley get in basic functionality 
fixes right now. Maybe in the next release!

7) Once again we are having a hard time just getting basic fixes in, let alone 
entire dialog changes. Plus I believe this would require me to modify my portion 
of the code in the main image dialog, which they wont let me touch.
(1, 2) If you want this to be a separate editor rather than a dialog, then you're 
going to have to get rid of the `Ok' and `Cancel' buttons, as well as the
dialog-style padding around the window border. But I think presenting it as a 
separate editor makes it unnecessarily complicated, and unhelpfully blurs the 
distinction between files (which usually are edited by UIs with File menus) and 
elements within files (which usually aren't).

(3) I said the toolbox, as distinct from the toolbar. I have never seen any other 
app with borderless (or onmouseover-bordered) toolbox buttons, but that could be 
because I haven't exposed myself to enough shoddy Windows shareware.

(6) Yes. Except in applications where two-dimensional editing is absolutely 
integral (e.g. paint programs), keyboard access should be provided to everything. 
You are lucky in that HTML image maps are represented at the file format level by 
SGML elements and attributes, which are relatively easy to represent using a 
keyboard-friendly GUI.

The menus can not be removed! They contain functions that are not available 
anywhere else in the UI (i.e. edit hotspot properties). Originally I had this 
thing designed as a separate application. The OK/Cancle buttons were added when 
the Netscape team decided they wanted to make it a child of the image dialog. I 
know it's unconventional and against the rules, but that's the way it has to be, 
sorry!

"I have never seen any other app with borderless (or onmouseover-bordered) 
toolbox buttons, but that could be because I haven't exposed myself to enough 
shoddy Windows shareware."

All of the buttons in Netscape and IE are flat, unless hovered over. CorelDRAW 9 
uses the same flat button technique for all the buttons in it's interface, 
including the ones in the toolbox. That techniques is also used in the entire MS 
office suite and the entire Windows 98 OS for that matter. In fact those style 
buttons seem to be the norm for most modern Windows software, and the old style 
bordered buttons seem to be going the way of the dinosaurs.

The only thing I would like Brian to do is to get toggle buttons to actually 
toggle, and see if he can get the tools to align to the top rather then the 
center of the toolbox (perhaps put an empty box below the tools with 
flex="100%"?).

Dan
That's not "the way it has to be".

Currently, the image map dialog is like a bastard child of a main top level 
window, and a dialog; it's modal, coming up over another dialog, but has its own 
toolbars and menus. It cannot remain this way -- it violates too many HI rules, 
as mpt has carefully listed.

We have scope before the next major Netscape release to redesign it, integrating 
it better into the rest of the UI. Think with that in mind, rather than minor 
tweaks to the existing stucture.

Therefore this should be the forum for that re-design.  Perhaps Matthew's 
proposed spec would be a good place to start.
Blocks: 58049
Blocks: 58050
Oh.  There's a bug on this... I have a huge clean-up patch for the image map 
editor in my tree, if that will help.
Blake,  please post your patches as an attachment to this bug.  I have some
patches too, so perhaps we could compare / merge.  Does your patch keep the
current look or is it a radical overhaul?

Also, Matthew has posted a mockup of a new proposed dialog on n.p.m.editor.  I'm
re-producing here for reference.

+--------------------------------------------------------------+
| Image Map for world.png :::::::::::::::::::::::::::::::::::::|
+--------------------------------------------------------------+
| ID of _map for image: [world-map       ] [^] ( :.. :.. ... ) |
|                                                              |
| +-Current _hotspots-----------+  Hotspot properties          |
| |                             |                              |
| | [non-graphical order    :^] |  _ID:     [africa      ]     |
| | +-----------+-+ [ A Up    ] |  _Link:   [africa.html ] [.] |
| | |e europe   |:| [ V Down  ] |  Ta_rget: [            ] [^] |
| | |e asia     |:|             |  _Alternative text:          |
| | |e:africa:::|:| [ Add ... ] |  [Africa                   ] |
| | |e america  |V| [Duplicate] |  _Title:  [African division] |
| | +-----------+-+ [ Delete  ] |  _Shape:  [polygon       :^] |
| +-----------------------------+  (  _Edit Coordinates ...  ) |
|                                                              |
| [\]+-----------------------------------------------------+-+ |
| [Q]|OOP                  OOOO  O "OPOOOOO OOOOOOOOOOOOOOO|A| |
| [R]|P                 *--odOOOO------*OOOOOOOOOOOOOOOOOOO|:| |
| [C]|"                 | dOOOOOOOOOOOOO\OOO^OOOOOOOOOOOOOO|:| |
| [P]|  o               |OOOOOOOOOOOOOOO^\OOOOb  "OOOOOOOOO|:| |
|    |                " |OOOOOOOOOOOOOOOO \OP"     OOP   "O|:| |
|    |""dObooo          *._OOOOOOOOOOOOOOOb*o       "o    O|:| |
|    | dOOOOOOO            `-._"OOOOOOO^OOO|             "d|V| |
|    +-----------------------------------------------------+-+ |
|    +-----------------------------------------------------+-+ |
|    _Zoom: [Actual pixels :^]  Ima_ge: Hide ========O= Show   |
|                                                              |
| ( Advanced ... )                       ( Cancel ) ((  Ok  )) /
+-------------------------------------------------------------/+
Hmm, OK.  My patch turns it more into a window than dialog (e.g. removes the 
buttons but keeps the menus, makes it non-modal and resizable) because I 
envisioned this as becoming a more fully-featured image[-map?] editor in the 
future.  But if that's not the case, I do like the mock-up...
Composer opens the image map editor from the Image Properties dialog. So if the 
editor is turned into a non-modal document-style window (i.e. one which has 
menus) rather than a dialog or secondary window (which doesn't have menus), won't 
we have the same problems as we had when opening help windows from modal dialogs 
in various other bugs?

Again, I don't think the image map editor (in Mozilla, at least) should be a 
document-style window with menus -- because it is not an application in itself, 
and because it is not editing a document (only an object within a document). 
Making it resizable would still be a good idea (as shown in the bottom right 
corner of my mockup:-).

More complete spec coming shortly.
Blocks: 61262
Do you want me to go ahead and do this re-work?  Dan can not guarantee his time 
to re-work the functionality but I have no problem doing the UI.
Brian--if you and Matthew (and Simon?) can agree on how to clean up the UI, go 
ahead and do it!  :-)
Good luck!

(is the url above still valid or are the specs elsewhere now?)

The url is still valid Kathy, but the page is not really relevant any more.  
Perhaps I could do a mock-up of Matthew's design and post it there.
Blocks: 61258
May I add to the complaints about mixing window and dialog components.

Because the window is not classed as a dialog the background is the wrong colour
(at least in my skin :-) for the OK and Cancel buttons. Nor are there any ids or
classes I can style to change the background colour of this dialog/window...
I will remedy this in the next round of changes which are being looked into 
right now. The window will definitely be taking on more properties of a dialog.
This patch addresses a number of bugs, but mainly cleans up the UI and removes 
the contrast and help menu items. When this is checked in, I will address each 
bug individually and submit patches to those bugs. Here is a list:

The bugs that this change addresses are:
http://bugzilla.mozilla.org/show_bug.cgi?id=58050
http://bugzilla.mozilla.org/show_bug.cgi?id=61035
http://bugzilla.mozilla.org/show_bug.cgi?id=61262

I'm going to start looking at functionality next:
http://bugzilla.mozilla.org/show_bug.cgi?id=37788
http://bugzilla.mozilla.org/show_bug.cgi?id=58049
http://bugzilla.mozilla.org/show_bug.cgi?id=61038

Many of these overlap, so fixes for some will clear parts of others.
Does anyone (MPT) know what the valid targets are for image maps links? I could 
not find solid answers after a web search. My guess is that it can be any web 
resource, whether that be another page, an image or a script (or even a mailto: 
link). I would say the filter should be an 'All Files' one, and then let the 
browser handle it after that.
URL: http://www.clubi.ie/kings/brian/moz/i...
> Does anyone know what the valid targets are for image maps links?

Same as all other links :-)

Which is why I suggest using "HTML" as default for file picking. Mostly they
will paste in a URL from some other source (i.e., use an "http:", not "file:")
Besides, "All Files" filter is still available.
Patch comming...


sr=kin@netscape.com on the 04/30/01 10:50, 05/02/01 16:07, and 05/02/01 16:52 
patches.
I still favor using 'GetLocalFile("html")', but "05/02/01 16:52" patch is still
a good idea. Allows us to use 'GetLocalFile(null)' when we do want just
"All Files" filter.


checked in. I'll let Brian mark bugs fixed.
Marking as LATER - this feature has been disbaled - see:
http://bugzilla.mozilla.org/show_bug.cgi?id=82802
1.0
Target Milestone: --- → mozilla1.0
Is there also a bug about re-enabling it when it is in a better state?
filed bug 84303 about turning it on.
Blocks: 84303
Component: Editor: Core → Editor: Composer
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Product: Browser → Seamonkey
Assignee: brian → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: mozilla1.0.1 → ---
This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
This bug is being marked EXPIRED as it has seen no activity in a very long time.

If you think that the issue reported might still be relevant, please test with a recent release of SeaMonkey and if the problem persists feel free to re-open the report. Thank you.

http://www.seamonkey-project.org/
Bulk reopening incorrectly expired bugs - no activity does not constitute no bug - these need proper checking.
Status: RESOLVED → REOPENED
Resolution: EXPIRED → ---
Patches appear to be checked in.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: