Re: Conlang Flag: Voting

I'm not sure if I sounded argumentative in my original post, or if you
are unintentionally sounding so to me in reply. I just wanted to say
explicitly that it's not my intention to be argumentative, and I'll
give you the benefit of the doubt as well. I'm just giving feedback,
and you're just responding to it. :)

Emaelivpeith Adrian Morgan:
> It was originally a vertical list - no table - but, as I'm sure you'll
> remember, Jan van Steenbergen wrote:
>
>     Oh, and one suggestion: place the flags in a table instead, so
>     that the page will show two flags next to each other. And use a
>     table border too, so that it becomes clear immediately which label
>     belongs to which flag.
>
> I changed it because of that feedback, and only for that reason.
> Personally, I'm happy either way.
I agree with Jan, a table is a good idea. I just don't agree that a
*single-row* table is great. :)

For an example of what I mean, go here:

    http://arthaey.mine.nu:8080/~arthaey/flagvote.html

The layout would be even better, I think, if the table could be to the
right of the form, but since I'm sure most people's monitors aren't
large enough to accomodate that, I've kept the table at the bottom of
the page.

> I don't understand what you're referring to. There is nowhere on the
> pages that the flags are referred to by numerals, unless you're
> seeing something I'm not.
No, I'm just seeing things. Sorry 'bout that.

> > 3. It *might* be a good idea to include a "Comments" text field with
> > each preference indication, so that we have more opinions to work with
>
> IMO, the list has been, and continues to be, the right place for
> mentioning and discussing comments on flags. The voting form isn't
> intended for that purpose.
Okay, convinced. Like I said, I only thought this suggestion *might* be good.

> > 4. To lessen the chance of invalid data entry, you could change the
> > text fields to drop-down menus.
>
> It's a thought, but thinking about it on the spot I suspect that
> typing the codes is faster for most people. The more I think about it,
> the more certain I am about this. Presumably people vote by scribbling
> their list of preferences on a scrap piece of paper and then copying
> this data into the form. Incidentally, I've never used drop-down menus
> in web forms, so that would be new for me.
Drop-downs are easy:

    <select name="choice1" size=1>
        <option>The Only Choice</option>
    </select>

But I suppose it makes small difference, either way.

> > 6. Also WRT the graphics, resizing *all* of the to a standard size
> > would probably be a good idea, just for fairness of comparison's sake.
>
> However, there's no escaping the necessity of viewing the flags the
> way the designers intended (especially, for example, the babel tower
> with the thin gold lines). If I scaled them to a standard size, I'd
> have to display both the standardised version and the original. Does
> this really provide any substantial benefit?
While I understand your concern over resizing images and getting ugly,
not-as-originally-intended-to-be-viewed results, I disagree that in
this particular case it causes substantial harm. These are simple
drawings, even the ones with fine lines. Only flag S's lines are
noticeably thinner-looking against the black background; everyone else
comes through fine.

Additionally, I would bet that most of us who decide to put these
graphics on our webpages won't want them being over 600 pixels wide,
as some of the flags are. If the design is intrinsically bad-looking
at smaller sizes, perhaps it's not the best design for web-use. (And
yes, I do know that resizing from the original source file, if it's
vector-based, or redrawing at the smaller size, would be crisper than
my brute force resizing. Even so, I don't see any horrible difference
between the originals and my resized versions.)

So, I think that the table layout with the standardized flags is much
easier to read, especially for comparing variations of one design. The
3-column layout *should* fit horizontally across screens running
higher than 8000x600 resolution.

> > 7. If you enter invalid data into the form and submit it, it displays
> > the errant items in reverse order -- that is, preference 24, then 23,
> > then 22, etc, with preference 1 at the bottom of the list.
>
> Indeed it does (if you enter invalid codes): is this a problem? The
> code is simpler that way, on account of the fact that it identifies the
> last non-blank entry before deciding which entries are invalid. OTOH,
> if you enter the same ID code in more than one entry, you'll find that
> it reports that kind of error in the opposite order. Surely the error
> messages are just as understandable no matter what order they are
> presented in.
*shrug* I found it strange, but no, it's not a show-stopper by any stretch.

> > 8. You cannot have blank entries between otherwise valid entries. I
> > don't know how often people would be doing that, but perhaps it might
> > be common enough that users miss one entry that it would be worthwhile
> > for you to just ignore all blank entries.
>
> I see no advantage in allowing people to skip entries. This *could* be
> handled, but it's one of those situations where you have to decide if
> there's a benefit that outweighs the extra effort. IMO the benefit is
> negligible, and I've no intention of including slick code merely for
> the purpose of showing off (for a commercial application, the
> effort/benefit tradeoff could well be different). If someone does
> accidentally skip an entry, I'd say the chances are considerable that
> they've made some other mistake, anyway. It's easier to accidentally
> enter the wrong code than it is to accidentally skip an entry.
Again, I agree, it's not that big a deal. I was merely noting things I
thought could be improved. Then again, part of my job at work is to
report UI bugs, so I may be being too perfectionistic for this webpage
that we're only going to use once. :)

> Another suggestion I have received is to change the caption on the
> first Submit button to make it clear that the vote is not submitted
> immediately. I intend to do this.
That sounds like a good change.

And please, Adrian and everyone else interested, let me know what you
think about the table redesign.


--
AA

Reply