[andy/viking.git] / TODO-REID

STATUS

1. Done
2. Trivial, can do if want
3. Already done; needs some reworking
4. I tried; I can always try again!
5. a. done
   b. Brilliant!
   c. impossible
6.

Dear Evan and list,

I spent the afternoon today tinkering with Viking 0.1.0, and came up with
the following list of criticisms. I hope that you all will find these
constructive, and I do regret that I have time only to criticize and not
contribute myself. Also, let me emphasize that Viking is damn cool, and
these are only ways to make it even better.

In terms of context, my current use of Viking is to plan backpacking trips.
I basically download the topos of areas of interest, and then draw in
potential routes using the track tool. I then export the images to the GIMP
and hack them further. Here is one example:

  http://reidster.net/trips/halls-ck-lower-escalante-loop/

Comments, of course, welcome.

Again, thanks for all the hard work on Viking! I hope to contribute myself
one day.

Reid


Constructive Criticism for Viking
---------------------------------

 1. Use autoconf/automake. Currently, if things (e.g. gtk, glib) are missing,
    the build simply fails, sometimes quite spectacularly. This will also
    bring in all sorts of handy niceties such as an "install" make target,
    etc.

 2. The top-level map directories appear to have the form "tZsXXzYY". Does tZ
    stand for "type Z" where type is terraserver, google, expedia, etc.? If
    so, I suggest using a word rather than a number for greater transparency.

 3. There ought to be a way to re-download map tiles, in case you mess with
    the files on disk like I did and download some aerial photos into the
    topo area.

 4. Panning (which is scads faster than v0.0.9, BTW) leaves screen junk in the
    panned-into region. Perhaps this area could be filled in with a solid
    color (say, a light steel gray?) until the new image can be drawn?

    I do really like that panning is lightning-fast, and drawing new data is
    deferred until I stop dragging.

 5. I like that downloading maps doesn't bring up a new window anymore.
    However, there needs to be more feedback on what is going on. I'd like to
    see the following:

    a. Status indicator somewhere saying how many maps are waiting to be
       downloaded.

    b. Map tiles which are blank but queued for download are highlighted in
       some way (say, color them pink?).

    c. Map tiles are drawn as soon as they are available. Currently, new tiles
       aren't drawn in until another redraw event comes in.

 6. Changing zoom level to a large scale (e.g. zoom out 64x) is slow, esp. if
    you only use the 4x4 meter resolution topos, as I do. This slowness is
    fine, but I think there ought to be an indicator that Viking is thinking
    -- the watch cursor, perhaps. I don't think a full-blown percentage bar
    window is necessary.

 7. Resizes to the layer info panel (or, the window config in general) should
    stored in the Viking file so they're persistent across sessions.

 8. It should be clearer which tool is active. Each tool should have its own
    cursor.

 9. Visibility of the start/end trackpoints of a track should be controllable
    independently of the visibility of interior points. I think that it would
    also be handy if, near the start/end trackpoints, "Foobar start" and
    "foobar end" could be drawn, since otherwise I forget the tracks' names
    and I don't remember which little symbol is the end and which is the
    beginning.

10. There should be a concept of a "current track". The current track should
    be drawn in a different color, and it should be highlighted in the list in
    the same color. The "Create Track" tool should extend the current track by
    adding on to the end point.

    Also, it's important to be able to have no current track; in this case the
    Create Track tool will start a new track. At the moment, I can't figure
    out how to start a brand new track after I've been editing one without
    restarting the program. Perhaps separate Begin Track and Extend Track
    tools would be a good idea?

11. Track colors are kind of strange under "Track drawing mode: draw by
    track". Here are some suggestions:

    a. Once a track is assigned a color, it should never change except by the
       user changing its color directly. (There might be a global "recolor
       tracks" command, in case the user wants help.)

    b. There needs to be more contrast between the auto-assigned colors, and
       the number of colors doesn't need to be too big. I would say, pick
       three or four contrasting colors and rotate between them.

    c. When a path is split at a trackpoint, the portion closer to the end
       point should be the one to change color. Perhaps a secondary dialog
       box listing the two new tracks, their names, and their colors, with
       opportunity to edit the last two items?

    d. A path's color should appear in its list entry, too. Perhaps a small
       square by the name?

12. I might further increase the contrast of the current trackpoint (selected
    with the edit trackpoint tool). Perhaps rather than changing its size,
    draw a big bold crosshair centered on it?

13. Tracks names should permit mixed-case.

14. IMO, being able to customize the background color is an unnecessary
    feature, and should be removed to ease maintenance.

15. I would rename the menu item "Zoom To..." to "Zoom to Custom..." and the
    "Zoom" submenu to "Zoom To".

16. Type size in the layer list should be configurable.

17. Perhaps dragging with the middle button should pan. I think this would
    complement well the existing center at location of middle click.

18. Deleting something big, like a track or a layer, should have a
    confirmation box.

19. It would be nice to have more information in the interface about which
    maps will be used depending on the "zoom level" of a map layer. For
    example, in a Terraserver topo layer, I had to discover by trial and
    error that <= 8x means "use 24,000:1 topo maps" and >= 16x means "use
    100,000:1 topo maps".

20. Consider an XML file format rather than the existing ad-hoc one.

21. The ability to rotate and move waypoint text would be fabulous.

22. When moving waypoints, it would be great if a greyed copy of the waypoint
    text and dot moved with the mouse.

23. I'd like the ability to customize the waypoint dot symbol. Personally, I'd
    prefer an X to the dot.
Commit	Line	Data
50a14534 EB	1	STATUS
50a14534 EB	2
10aae26b	3	1. Done
50a14534 EB	4	2. Trivial, can do if want
	5	3. Already done; needs some reworking
	6	4. I tried; I can always try again!
	7	5. a. done
	8	b. Brilliant!
	9	c. impossible
	10	6.
	11
	12	Dear Evan and list,
	13
	14	I spent the afternoon today tinkering with Viking 0.1.0, and came up with
	15	the following list of criticisms. I hope that you all will find these
	16	constructive, and I do regret that I have time only to criticize and not
	17	contribute myself. Also, let me emphasize that Viking is damn cool, and
	18	these are only ways to make it even better.
	19
	20	In terms of context, my current use of Viking is to plan backpacking trips.
	21	I basically download the topos of areas of interest, and then draw in
	22	potential routes using the track tool. I then export the images to the GIMP
	23	and hack them further. Here is one example:
	24
	25	http://reidster.net/trips/halls-ck-lower-escalante-loop/
	26
	27	Comments, of course, welcome.
	28
	29	Again, thanks for all the hard work on Viking! I hope to contribute myself
	30	one day.
	31
	32	Reid
	33
	34
	35	Constructive Criticism for Viking
	36	---------------------------------
	37
	38	1. Use autoconf/automake. Currently, if things (e.g. gtk, glib) are missing,
	39	the build simply fails, sometimes quite spectacularly. This will also
	40	bring in all sorts of handy niceties such as an "install" make target,
	41	etc.
	42
	43	2. The top-level map directories appear to have the form "tZsXXzYY". Does tZ
	44	stand for "type Z" where type is terraserver, google, expedia, etc.? If
	45	so, I suggest using a word rather than a number for greater transparency.
	46
	47	3. There ought to be a way to re-download map tiles, in case you mess with
	48	the files on disk like I did and download some aerial photos into the
	49	topo area.
	50
	51	4. Panning (which is scads faster than v0.0.9, BTW) leaves screen junk in the
	52	panned-into region. Perhaps this area could be filled in with a solid
	53	color (say, a light steel gray?) until the new image can be drawn?
	54
	55	I do really like that panning is lightning-fast, and drawing new data is
	56	deferred until I stop dragging.
	57
	58	5. I like that downloading maps doesn't bring up a new window anymore.
	59	However, there needs to be more feedback on what is going on. I'd like to
	60	see the following:
	61
	62	a. Status indicator somewhere saying how many maps are waiting to be
	63	downloaded.
	64
	65	b. Map tiles which are blank but queued for download are highlighted in
	66	some way (say, color them pink?).
	67
68	c. Map tiles are drawn as soon as they are available. Currently, new tiles
69	aren't drawn in until another redraw event comes in.
70
71	6. Changing zoom level to a large scale (e.g. zoom out 64x) is slow, esp. if
72	you only use the 4x4 meter resolution topos, as I do. This slowness is
73	fine, but I think there ought to be an indicator that Viking is thinking
74	-- the watch cursor, perhaps. I don't think a full-blown percentage bar
75	window is necessary.
76
77	7. Resizes to the layer info panel (or, the window config in general) should
78	stored in the Viking file so they're persistent across sessions.
79
80	8. It should be clearer which tool is active. Each tool should have its own
81	cursor.
82
83	9. Visibility of the start/end trackpoints of a track should be controllable
84	independently of the visibility of interior points. I think that it would
85	also be handy if, near the start/end trackpoints, "Foobar start" and
86	"foobar end" could be drawn, since otherwise I forget the tracks' names
87	and I don't remember which little symbol is the end and which is the
88	beginning.
89
90	10. There should be a concept of a "current track". The current track should
91	be drawn in a different color, and it should be highlighted in the list in
92	the same color. The "Create Track" tool should extend the current track by
93	adding on to the end point.
94
95	Also, it's important to be able to have no current track; in this case the
96	Create Track tool will start a new track. At the moment, I can't figure
97	out how to start a brand new track after I've been editing one without
98	restarting the program. Perhaps separate Begin Track and Extend Track
99	tools would be a good idea?
100
101	11. Track colors are kind of strange under "Track drawing mode: draw by
102	track". Here are some suggestions:
103
104	a. Once a track is assigned a color, it should never change except by the
105	user changing its color directly. (There might be a global "recolor
106	tracks" command, in case the user wants help.)
107
108	b. There needs to be more contrast between the auto-assigned colors, and
109	the number of colors doesn't need to be too big. I would say, pick
110	three or four contrasting colors and rotate between them.
111
112	c. When a path is split at a trackpoint, the portion closer to the end
113	point should be the one to change color. Perhaps a secondary dialog
114	box listing the two new tracks, their names, and their colors, with
115	opportunity to edit the last two items?
116
117	d. A path's color should appear in its list entry, too. Perhaps a small
118	square by the name?
119
120	12. I might further increase the contrast of the current trackpoint (selected
121	with the edit trackpoint tool). Perhaps rather than changing its size,
122	draw a big bold crosshair centered on it?
123
124	13. Tracks names should permit mixed-case.
125
126	14. IMO, being able to customize the background color is an unnecessary
127	feature, and should be removed to ease maintenance.
128
129	15. I would rename the menu item "Zoom To..." to "Zoom to Custom..." and the
130	"Zoom" submenu to "Zoom To".
131
132	16. Type size in the layer list should be configurable.
133
134	17. Perhaps dragging with the middle button should pan. I think this would
135	complement well the existing center at location of middle click.
136
137	18. Deleting something big, like a track or a layer, should have a
138	confirmation box.
139
140	19. It would be nice to have more information in the interface about which
141	maps will be used depending on the "zoom level" of a map layer. For
142	example, in a Terraserver topo layer, I had to discover by trial and
143	error that <= 8x means "use 24,000:1 topo maps" and >= 16x means "use
144	100,000:1 topo maps".
145
146	20. Consider an XML file format rather than the existing ad-hoc one.
147
148	21. The ability to rotate and move waypoint text would be fabulous.
149
150	22. When moving waypoints, it would be great if a greyed copy of the waypoint
151	text and dot moved with the mouse.
152
153	23. I'd like the ability to customize the waypoint dot symbol. Personally, I'd
154	prefer an X to the dot.
155
156
157
158