Bug 230690 - s-c-d: timezone selection need polishing
Summary: s-c-d: timezone selection need polishing
Alias: None
Product: Fedora
Classification: Fedora
Component: system-config-date
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nils Philippsen
QA Contact:
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-03-02 07:40 UTC by Bernard Johnson
Modified: 2009-03-25 10:15 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-25 10:15:13 UTC
Type: ---

Attachments (Terms of Use)
fedora tz selection (132.68 KB, image/png)
2007-03-02 07:40 UTC, Bernard Johnson
no flags Details
ubuntu tz selection (103.46 KB, image/png)
2007-03-02 07:42 UTC, Bernard Johnson
no flags Details
demonstration of one weakness of zoom (64.17 KB, image/png)
2007-03-02 07:42 UTC, Bernard Johnson
no flags Details

Description Bernard Johnson 2007-03-02 07:40:41 UTC
Description of problem:

I was descrbing to Jeremy on irc that I thought s-c-d timezone selection needed
some polish.  I had once booted a Ubuntu live cd and noticed that theirs a)
looked better and b) operated better than ours.

This is pretty subjective stuff, but I'll try to describe it as best as I can
(I'm no interface designer either).

1) I believe that the overall colors of the timezone selection screen are too
dark.  I'm attaching the ubuntu-tz.jpg from Ubuntu.  Notice how rich the colors
are compared to fedora-tz.jpg?

2) I've never really cared for the zoom approach of selecting a timezone.  I
understand that it's hard to select a tiny dot (and some are very close
together), but it has created additional problems.

  a) Zoom is not smooth when you select a region.
  b) Zoomed regions contain dots that can't be selected (see fedora-tz2.png).
  c) Dots in desert regions have little contract (yellow on brownish orange).
  d) User is forced to select a timezone before exiting zoom (yes, there are a
few places to click that exist without selecting, but they are hard to find).

That being said, I don't think zooming to a more detailed region is a bad idea.
 In fact, you pretty much have to because of the proximity of some of the dots.
I just think that this is not the best implementation of that. (No, sorry, no
breakthrough ideas either)

3) The elastic arrow looks a little clunky - amatuerish.  I didn't get a
capture, but Ubuntu just lights up the nearest dot.  Also their "dots" are
slightly larger orange diamonds, which IMHO provide greater contrast given their
overall color scheme.

Version-Release number of selected component (if applicable):

Comment 1 Bernard Johnson 2007-03-02 07:40:43 UTC
Created attachment 149089 [details]
fedora tz selection

Comment 2 Bernard Johnson 2007-03-02 07:42:00 UTC
Created attachment 149090 [details]
ubuntu tz selection

Comment 3 Bernard Johnson 2007-03-02 07:42:54 UTC
Created attachment 149091 [details]
demonstration of one weakness of zoom

Comment 4 Nils Philippsen 2007-04-26 07:19:55 UTC
Hi Bernard,

I've made some changes, especially to the way zooming works, in the development
version of the tool. The TZ selector the Ubuntu people have looks awfully
similar to the one in Evolution, so I just tried out that one. I don't think I
like that color scheme, even though it's easier to get the contrast right. And
even though the arrow might seem amateurish, I find it much easier to spot the
currently selectable city with it than with only a highlighted dot. Although,
with the current version there's a label of the selectable city more or less
beside it... I have to think about that one.

Please take a look at the current version. You can check out the current code
from CVS (unfortunately the built packages haven't made it onto the mirrors yet):

1.) Log into anonymous CVS with an empty password (just hit return):
cvs -d :pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS login
2.) Check out the current code:
cvs -d :pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS co -z4
3.) change to the system-config-date/src directory
4a.) now you can start the whole thing:
4b.) or only the TZ widget:
python ./timezone_map_gui.py

I'm still thinking about how to improve the contrast of the city dots, so if you
have some ideas in this area or something else please shout.

Comment 5 Bernard Johnson 2007-04-27 15:39:15 UTC
(In reply to comment #4) 
> I've made some changes, especially to the way zooming works, in the development
> version of the tool. 

When I zoom, I can only zoom to the middle of the map (towards the West coast of
Africa).  How can zoom in on, for example, all the islands in the Pacific? 
There are no scroll bars when I run it.

Comment 6 Nils Philippsen 2007-04-27 16:48:53 UTC
A tooltip should have told you what to do, but I've added scrollbars so that
it's obvious. This is not yet packaged, so you need to check CVS to see it for
now. I plan to build an updated package with updated translations mid-next week

Comment 7 Bernard Johnson 2007-04-28 19:16:29 UTC
I guess I didn't notice the tooltip :)  The scrollbars make it pretty obvious

The yellow dots aren't a lot of contract on the desert areas.  I was going to
suggest a two color dot (one color ring + center fill), but I just noticed in
the code that it's an actual character, so that wouldn't work.  This is why I
was suggesting the map color changes - better contrast.  Is there a way to make
the dots stand out more on all the current map colors?

The labels are very helpful.

Also, I notice that when I zoom (this was a problem with the previous version
too), the map moves, then quickly redraws.  This usually has the effect of
seeing part of a continent move somewhere else, quickly replaced by the zoomed
in/out map.

Comment 8 Nils Philippsen 2007-10-09 15:46:10 UTC
Changing the product version to devel to not lose track of the bad contrast
thing. The redrawing "effect" would be a problem in the GnomeCanvas used, it
seems to immediately draw the changes when doing the move instead of waiting
until the GUI mainloop is serviced.

Comment 9 Jeremy Katz 2007-10-09 15:56:41 UTC
Nils -- the redrawing could be due to bug 289281

Comment 10 Nils Philippsen 2007-10-10 08:31:59 UTC
(In reply to comment #9)
> Nils -- the redrawing could be due to bug 289281

I can't say I know anything about it, but reading the bug it rather seems like
"Federico's tearing patch" would have solved this problem here (if it worked)
but caused bug 289281 -- right?

Comment 11 Bug Zapper 2008-04-03 19:20:06 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 12 Nils Philippsen 2008-04-04 08:24:34 UTC
The bad contrast in some areas is still an issue.

Comment 13 Bug Zapper 2008-05-14 02:39:30 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 14 Nils Philippsen 2009-03-25 10:15:13 UTC
I'll close this now, as item 2 of the original report is fixed since quite a while and items 1 and 3 are a minor things and a matter of taste really.

Note You need to log in before you can comment on or make changes to this bug.