My 'laundry list' of problems, questions, comments, concerns
Posted by:
rob (IP Logged)
Date: May 24, 2009 06:20PM
(Let's see if this message board can take a listing/message this long!)
What follows is the list of things I've noticed not working, working poorly, bothersome, annoying, or differently than I would hope or expect, broken from pre-cutover, or whatever. They are in absolutely NO order (of importance or much else) (though some attempt at grouping similar or related stuff), and include some items I have reported/recorded elsewhere (other messages on message board or trouble tickets. I repeat them here just to attempt one comprehensive list.
I really don't mean to 'complain' or 'pile on' to the heap of woes already being pursued. I mean only to report things I've noticed as I have tried to work with the newly cutover system. Please note that I think a great many of the things being attempted are AWESOME improvements in functionality in the system. However, it seems there are an inordinate number of things which are not up to the quality that general users and StreamTeamers should expect from AW.
So, without further do-do:
1) StreamTeam function button/bar (Edit/Edit Flows/Resign/...) - location
Having this 'edit/action button bar' so immediately adjacent to the 'Tabs' bar seems to make it far too easy to inadvertently click an edit/action button when one really wanted to click a 'tab'. (Obviously, this only applies to us StreamTeamers, but . . .) It would seem better to have the 'Edit/action' buttons NOT be in the same (light green) 'box' as the tabs are in, since they are inherently different in function. The existing light green box (which just allows users/STers to switch what information they are VIEWING. The 'action' buttons (which allow adding/changing information presented) should be in their own 'box' (perhaps a light/dull yellow or orange), either above or below the light/dull green 'Tabs'/viewing bar.
2) StreamTeam function button bar (Edit/Edit Flows/Resign/...) - button sequence
The StreamTearm function buttons should be in a more logical sequence (and, should either all have intial capitalization, or all not).
(a) 'Report Level/Upload Photos' and 'Comment/Warn' appear for all users (not just STers), and might be expected to be most used, so should be first in the line.
(b) For STers, next to the 'Comment/Warn' button, it would make sense to have the 'Remove Comment' button.
(c) 'Edit' & 'Edit Flows' seem to go together, and should be next, as they would be most used (by STers, to whom they will appear).
The remaining buttons are (or should be) essentially virtually 'one time only' buttons, and should be grouped ('boxed') separately.
(d) 'Accept' and 'Resign' go together. Ideally, it would seem they are complementary and mutually exclusive functions. If you aren't the ST on a reach, you can't 'Resign', you can only 'Accept'. If you are the ST on a reach, you can't 'Accept' again, you can only 'Resign'. Thus, it would be cool if the system would check your 'status' regarding the reach, and display only the appropriate button. However, failing that luxury (of having only the appropriate one of the buttons appear), the two buttons should appear together.
(e) 'Publish', 'Verify' and 'Unverify' seem similar/related functions, thus should be 'grouped. 'Verify'/'Unverify' (as with 'Accept'/'Resign') are complementary and mutually exclusive functions. Only if a reach is not yet 'verified' should the 'Verify' option apply (and appear), and only if a reach is already 'verified' should the 'Unverify' appear. And, I'm guessing that the 'Verify' button appears to all STers, while the 'Unverify' button might appear only to the 'Regional Editors'. Or . . . there was (and should be?) a difference between having a button for an ST to 'request verification' versus a button for the 'Regional Editor' to 'Mark as Verified'. ('Unverify' might go either way -- perhaps an STer could be allowed to 'unverify' their own reaches, or we could be consistent (and anal) and have the STer 'Request Unverification', and have the 'Regional Editor' actually 'Mark as Unverified'.)
3) StreamTeam function button bar - 'Verify'/'Unverify' - do we even really need these?
I am not sure that this serves much purpose. Even with the mention at the top of the page ("Descriptions of reaches with River Name in bold have been verified by a regional StreamTeam member.") it is readily apparent (from comments on various message boards) that people don't really understand what this means. People are going to look at reaches they are interested in, regardless whether they have been 'verified' or not. They know (or soon will) that reaches vary in how 'robust' the info included is. I am equally certain different Regional Editors have different 'personal criteria' to decide what is 'necessary' for them to approve a reach as 'Verified'. As various new functionality has been added, it would seem some reaches which had previously been 'verified' might now be considered woefully inadequate (in the current function and layout of the website). Should a reach be marked as 'verified' if there are no rapids in the "Rapids" tab? If there is no shuttle information in the "Directions" tab? If there is no info in the "Flow Info" tab? Reaches which were 'verified' prior to the 'Tabs' being implemented had any/all that info 'in line', and may not have had that info 'split out' into the tabs subsequently.
Frankly, from the beginning, and even moreso now, I have never (personally, nor to 'my' StreamTeamers) put much emphasis on using the 'Verify' button. I suppose its 'main' purpose might be just to make a 'Regional Editor' aware of that some STer has worked on a reach . . . to alert 'someone official' to review what is being put on the AW site. This might be most appropriate for the case of a new StreamTeamer, as a way of checking the input (especially from someone with an 'unproven' track record) comes up to some basic 'standards' which we might want to expect or enforce, and so we can suggest improvements. However, as we have seen, we cannot always 'trust' even long-time STers who may become disgruntled and start 'sabotaging' the system in one way or another. Short of having some regional or other 'editor' approve ALL changes, there is really no reliable means of keeping any meaningful audit or 'verification' process.
4) "Make Changes Public" button (top of edit page) and "Update Edit Copy" button (bottom of edit page) . . . confusing
It is not clear to me what the difference is, or why there is a need for both of these buttons. Adding to the confusion is the claim at the top of the page that "The edit interface for rivers now tracks changes to the river when you switch tabs.". My 'logic' and intuitive sense of these suggests that (perhaps) the bottom button is to do a 'temporary save' of the changes on each part of the edit, which should then be shown if/when I go the the "Preview" tab. However, I made changes to the 'main description' for a reach, pressed "Update Edit Copy" button (bottom of edit page), then clicked the "Preview" button, and I did not see my changes.
5) Background Colors (for 'low' rivers) a bit bright/distracting
There is at least one comment on BoaterTalk taking issue with the "neon yellow". It hadn't struck me before, but it does seem a bit 'distracting' (overly bright), especially since it represents reaches which are 'too low' to run. If anything should 'stand out', it should be reaches which are 'runnable'. Field background on all else should be more 'muted' so those runs 'fade back' (visually), allowing the 'runnable' reaches to visually 'pop' (I.E., stand-out more). It seemed like the former color scheme had (somewhat more muted) orange/yellow-orange tones for the 'too low' range.
6) Font colors are behaving erratically
On a number of reaches, there are sections of text for which the font color has been set (in order to make certain information or warnings in the body of a description 'pop out'). However, various ways of looking at the text seem to 'ignore' the font/color settings.
Specifically, I'm looking at reach#2834, where the whole first paragraph is (should be) in red. However, in the Edit/Description tab, before I click the text box (to be able to edit the text), the first word ("NOTICE!!!") appears black, and the rest of the paragraph is red. Once I click the text box, it appears all in red (as it should be). When I'm in the edit/Preview panel it all appears as standard (black) text.
7) Column/Line order
Perhaps this is more a 'personal preference' thing, but . . . my sense of 'logical order' would suggest that each line/order should list 'State', then 'River', then 'Reach-name'. (As we used to list. I don't see why it needed to change to 'River', then 'State'.)
8) Row/River-Reach order
Multiple reaches on a given river appear in proper sequence on the initial listings (at least, all that I looked at). However, I noticed that if I click some other heading to sort (say, by relative level, r.c.), then click "River Name / Section", reaches end up out of sequence (on the 'regular' listing for a state, as well as the 'by drainage' listing). I'm almost certain this used to work fine in the old system, so I'm curious why it can't work with the new system.
9) Mouse-over on drainage map/list
Pulling up state by drainage yields a page with a state map on the left.
It's totally awesome that when I 'mouse over' the map, the corresponding description of the drainage is highlighted on the right!
Is there any chance that the reverse could also happen? I.E., as I 'mouse over' a description on the right, the corresponding drainage area on the map would be highlighted? That would really be cool!
10) Quebec rivers still showing up in "Wisconsin, by drainage"
I had called attention to this before, and my recollection (perhaps mistaken) was that it was expected to have been 'fixed' by the new system -- it hasn't.
11) River names hard to 'find'
We are getting somewhat 'slammed' (on BoaterTalk) about the new format. While virtually no one has directly expressed it this way, I have to suspect that part of the problem is a reaction to the reach being split into two lines. This just makes it harder to 'visually group' rivers with multiple reaches, and (for that matter) to quickly scan down the list to find a particular river. Yes, it helps a little that the font for the reach name is slightly smaller (or 'compressed' or whatever). It would help more if the river name would be boldface. (Yeah, we have used that for reaches which are 'Verified'. Does anybody really care about 'verified' reaches? Does hardly anyone bother with that? The system now does so much fairly automatically, it seems almost meaningless to bother with that anymore.) Yes, there is the (new) feature right at the top of the page (for a 'regular' state list . . . it doesn't show up on the list 'by drainage') whereby users can enter a state and "Partl. Name" (any reason that had to be abbreviated?), then click on the "Rivers" button to do a search on the river. However, that reduces the list to just the selected river(s), rather than scrolling down the list to the river, which would 'find' the river, but allow the user to still see the other rivers.
12) Reach names truncated
Longer reach names are being truncated (with ellipses), even though it appears there is plenty blank space after them. This truncation may become necessary if each entry is restored to a single line. However, (I don't know if this can conveniently be done but) I'd sooner see the text allowed to 'wrap' only when needed, and then only within the 'column' for Reach-name, so the River-name column would still stand by itself (I.E., no part of Reach-name would fall under the River-name column).
13) Page elements missing on "by Drainage" page
When a state river list is pulled up 'normally' (that is, NOT 'by drainage'), there is (for lack of a better term) a 'search bar' at the top of the page, and at the bottom of the page a "Network" tool (with corresponding check-boxes on each reach), as well as a "Share Information" box, and a "When Running" box. However, NONE of these items appear on the page when the state list is pulled up 'by drainage'. Was this an oversight (error)? Or strictly a design choice? Or is there something about the 'by drainage' list which otherwise precludes these features from working on that listing?
14) 'River Networking' (star icons)
These used to align nicely in a column between state and river/reach name.
New system puts these after river name (on line 1 of the two line entry for each reach.
This makes it harder to quickly see which reaches I'm 'in the network' for.
AND, one used to be able to just click the 'River Network' star/icon to 'join' the network for a river/reach.
Now one has to understand that the check-box must be checked (on the state list), then scroll to the bottom of the page, and click the appropriate button at the bottom for the action(s) they desire. This is not obvious.
15) Shared reaches not working
In the past, for 'shared reaches', I had just created a 'duplicate reach' (with only minimal, skeletal info), and implanted a script which automatically forwarded users to the complete listing in the other state which 'shared' the reach. The disadvantage to this old method was that both listings would show up when a 'by drainage' list was pulled up for either state. (Though in at least one instance, I used that to advantage!) So, now, it appears there is a 'multi-state' functionality which has been added. If this new feature works as I suspect it should, only a single reach/description would exist, which (I'm surmising) would show up on either (both) state listings? However, I've tried it, and I have not been able to see what it is supposed to do or to make it work. (The river/reach I was trying it on is #3222, which is shared between Wisconsin and Michigan. I already deleted the former duplicate skeletal reach in Michigan, but can't seem to make the Wisconsin reach 'keep' the added state of Michigan. I added Michigan to the list, then I tried the "add Selected" button, the "Update Edit Copy" button, and the "Make Changes Public" button, but nothing seemed to make it 'remember' Michigan.)
16) Gauge 'trend'
As I had previously (somewhere . . . an email to Ryan?) commented at length,
and as at least one comment on BoaterTalk has mentioned . . .
While the 'gauge trend' info (so-and-so-many cfs/hr up or down) SEEMS like a great addition,
I think (as currently implemented) it is almost completely worthless and (worse) misleading.
If you have ever CLOSELY watched gauge readings for many rivers at all,
you will see that even while the overall graph is trending upwards (or downwards)
individual readings posted (every 5 or 15 minutes, generally) can be (relatively) all over the place.
Take any two 'random' data points (from an hour apart or whatever) and they can show a 'trend'
which is the reverse of the overall trend shown by the graph.
Without doing some serious 'data smoothing' (averaging 5, 10, 15, or so readings)
and then comparing a 'averaged' reading from one point to some other point,
the value placed on the screen is relatively meaningless as best, and misleading at worst.
Even with this 'data smoothing', there is just too much variability across different rivers, gauges, and other circumstances.
The only reliable, meaningful way to show 'trend' is to show a graph of the gauge, as users can already get in a pop-up window by clicking on the gauge value.
17) Going into edit on a reach (in the new system), the division of information among the tabs seems illogical.
"Main" tab has lat/lng, which seems more like "Location" (the next tab).
"Location" tab has class, length, gradient, agency, all of which seem more like "Main" data.
"Location" tab has gauge description info, which should be in "Flows" tab.
18) Search: entering only "Level", "Low (below Min)" yields a "Fatal Error" message.
(Doing a search on only "High (above Max)" works fine.)
19) Search: I think some wires got crossed (so to speak).
Selecting (searching on) "Running (between min and max)" yields a list with rivers over the max.
Selecting (searching on) "Above Min" yields a list with NO rivers over the max.
(I think these need to be reversed.)
20) Abstract disappears too quickly
I love the little 'i' (info) icon, which (when hovered over) pops up the 'abstract' (run summary). For the longer abstracts, however, the pop-up disappears before I can finish reading. Sure, I can mouse-out/mouse-back and get it to re-appear, but that is annoying. Is there some reason this can't be made to stay visible longer? Or, for that matter, is there a reason it couldn't/shouldn't stay visible as long as the mouse/pointer is over the icon?
21) Abstracts truncated
As I've previosly reported, the abstract field (on the river edit page) SAYS it can be up to 240 characters. However, it appears to actually truncate at 145 characters.
22) Directions tab / Shuttle mapping default should be 'on'
Is there a good reason why the default on this (when building a new reach) is 'none', rather than defaulting to 'shuttle/custom from put-in lon'? I believe the vast majortiy of the time, the directions created by Google are correct (at least in my experience). It seems far more logical to have this 'on' by default, and then have the option of turning it off on those rare occasions that it is wrong. Otherwise, as it stands, one has to always remember to turn it on.
23) Message board log-in/post discrpancy
Any 'Netizen' (user) can access the "Community" "Forums". Actually posting a message requires user to be 'logged in'. However, the system displays a 'text input' box whether you are logged in or not! One can spend (sometimes even a heap-o-)time composing a message, only to press "Post message" and find out they are not logged in, whereupon the entire text of their message is LOST. They have to log in, and retype the (entire) message. OK, it's not like it happens a lot, but it is just wrong for it to it to be set up that it can happen at all. If a user is not logged in, the message/text entry box should not appear. In it's place should be a message saying "Log in to be able to post a message or reply."
24) Virtual Gauges now forced to be either "CFS" or "Ft."
I have two virtual gauges which USED to be set up to correlate USGS readings into readings on a historical 'paddlers gauge', which read in "inches". With implementation of the new release, these have now been 'forced' to have units of 'feet'. I completely understand USGS gauges all being forced into 'CFS' or 'Ft'. Granted, where possible, in the 'new order', using (and having boaters get used to) CFS is 'preferred', but some of us old-timers still like the 'comfort' of relating to all those runs of yore, when all we had was the 'bridge gauge' reading to go by. And, while the calculation certainly COULD be converted to report in 'feet', (1) this would be a bit confusing adjacent to the USGS stage reading (in feet), which is different, and (2) boaters for these two reaches (and I suspect there could be others) just always talked about readings in "inches", even when the river was at 12", 18", 24", and so on (we seldom, if ever, said 'a foot' or 'foot-and-a-half', or 'two feet', etc.) So . . . I suppose it's not a big deal in the grand scheme of things . . . there are bigger problems to pursue . . . I could just drop these virtual gauges . . . but it would be 'nice' if there were some way to accommodate units other than just 'CFS' and 'Ft', especially when we're talking about virtual gauges.
Rob Smage
AW member since 1992, volunteer since 2000, Midwest Regional StreamTeam Editor