Re: here's my collaborative proofing system you can look at

ok, do i dig lee's post out of my spam filter, or not? decisions, decisions, decisions... ;+) *** lee said:
On my system, my browser window is approx 1050 x 1600.
oh lordie. you make your interface work for the average case, and who reports back? the people who are _not_ average, that's who. a 1050*1600 browser-window is a _portrait_ viewport... are you really using a portrait monitor, lee, or are you just being perverse by arranging your browser-window that way? way back when i was a wee one, i worked for a professor who was consulting for xerox, so i saw the alto and bravo machines when they were still new, and i just assumed that we would all be using portrait page-sized monitors like on those machines. so imagine my disappointment when the landscape orientation of spreadsheets spread its wrong-ass orientation on computing, ensuring that we would wander in the desert for 30 years before we'd be able to see a full-page of text on an affordable monitor. and that would happen only because our still-landscape screens had now grown gigantic enough that we could see _2_ full pages! oh, along the way, i actually _tried_ using a portrait monitor. got some software that switched the orientation on my g3, so i could prop open the landscape clamshell laptop and stand it on its side. it was great for word-processing and desktop-publishing, but it was _lousy_ for web-browsing! why? because most web-pages are designed for landscape! eventually, as the web became more important, i relented... so i think lee and his portrait browser-window might well be having problems negotiating _any_ collaborative proofing site, not to mention almost any site at all these days, if we're real... but hey, who said reality had anything to do with this? :+) so lee, my first piece of advice to you will be the opposite of the advice i gave to jim -- namely, make your window wider! and/or make the text smaller. either one (or both) will work. if it's impossible to make your browser-window any wider (i.e., your monitor is that size), or if the text is so small already that you can barely read it, my advice is no good. in that case, i would create another design for your case, one that uses the vertical space rather than the horizontal, meaning i'd _stack_ the three displays on top of each other, such that you could see two out of the three at any one time. the top one would be the .html, the middle one the page-scan, and the bottom one the edit-field. (the user could reorder.) any system has to let the end-user make adjustments to it... like d.p. or fadedpage, i will probably have the user enter the desired values into a preferences box, as that is an easy way for a programmer to offer that functionality to users... i've also put the values right on the working-screen itself, rather than on a separate preferences screen, so i might do that once again. probably nicest is to offer divider-bars, which users can drag to change the way the screen is split. (even nicer would be to store the info for the user, so once they made the adjustment, it would stick as their preference; but so far i've been loathe to store any type of information.) anyway, thanks to jim and lee for bringing up the issues that arise around the issue of screen-size (and screen orientation). i was (and am) continually aware of them, thanks to being very fortunate in having had a very big monitor for over 6 years, but it's good to have it reinforced. especially with the netbooks and the iphone/ipad, the range of screensizes is now overwhelming.
the page image occupied a little more than two-thirds of the right-hand side of the screen and the apparent "smooth-reading" text occupied less than 1/3, resulting in a text reading screen that created line breaks in odd and unsettling locations
the aim is a 50/50 division, for a "facing-pages spread" look. anything different than that is going to cause problems, yes...
On the bottom half(?) of the page, the edit box (which, by the way, is much easier to read than the "smooth reading" presentation)
this tells us that lee does not have d.p.-monospace installed. :+)
is set to an absolute width that does not cause the odd word wrapping
yes, it doesn't. it doesn't have _any_ word-wrapping, and that's because i set the width of the edit-field to the width of the longest line in the edit-field. but, as we are about to find out, that is at times untenable.
but which makes the two boxes have more width than the width of my browser, causing the edit box to appear below, and to the left of the page image.
yes, that does happen. it happens _especially_ on the pages that had footnotes, because those footnote lines have a very large _width_ (i.e., number of characters), as they were printed _small_. so this experiment to size the edit-field according to its _contents_ didn't work, not reliably, and i will abandon it. (this is the _real_ error in the design. jim was focused on the "unnecessary" _whitespace_, but that's just valuable real-estate that can be used for another good purpose... this interface flaw, though, is more serious. easy to fix, as you decide to wrap the long lines in the edit-field or else use a horizontal scrollbar. one of these two options is largely unavoidable in some situations, as you know if you look at any of the other proofing-site interfaces.)
Believe me, I understand that getting a pleasing layout when you don't know and can't control the width of a user's browser is a difficult thing.
well, you _can_ know it, with a little javascript, but i have chosen not to use any of that, to keep my internals simple. and you _can_ control the width of the browser-window, by simply setting it when you open it and stripping away any resize potential; but it's not worth alienating the user. what fadedpage has done (as far as i can tell) is to build an interface that simply _demands_ a maximized window. the design doesn't adjust if the window gets smaller, so the user just can't see all of it. as good a solution as any. interface isn't "hard". but it's not easy either. over at d.p., they have two interfaces (and they're working on a third), and some people swear by one, and other people the other. customization is key.
there are two sets of radio buttons, one alternating between "b" and "c", and the other between "sho" and "no." I have no idea as to what these two sets of radio buttons accomplishes.
you could've tried them to find out. you know, curiosity. (that thing that killed the cat.) or i can just tell you... the b/c set stands for "button" versus "color". this controls the way that flagged words are displayed. the default is by "color", meaning that the flagged words are rendered in red. that makes them stand out, vividly, but it's all that that does. if you choose "b" for "button" instead, you will see that the flagged words are now rendered as _buttons_. clicking one of these buttons adds that word to the custom-dictionary, and the page is redrawn, showing the word now unflagged. the buttons are an extremely convenient way to add a word to the book's custom-dictionary. in fact, due to all the action, and the sense of progress, it's fun! but if there are _lots_ of flagged words on a page, adding 'em one-by-one is boring. ergo, i added the "bulk-add" button. all the flagged words are placed in the bulk-add field, and all words in that field are put in the dictionary when you click the bulk-add button. (so if any of those flagged words should _not_ be added, you should delete them from the bulk-add field before clicking.)
Above the edit box, but below the page image, there is an apparent edit box containing the hyphenated words "per- fect" and "cen- turies;" (but not the hyphenated word "moun- tain"; to the side there is a button labeled "bulk-add." I do not understand what any of these controls are for.
the hyphenated fragments are not in the dictionary, so they were flagged, so they are in the bulk-add field. i'll eventually improve my spellchecking routine, such that it will only flag hyphenated fragments if they're incorrect. in the meantime, the "bulk-add" capability is quite good...
It seems that the edit box is used to make corrections to the text as displayed above.
nope. it's only to add words to the custom-dictionary. i'm a little surprised that this seems totally foreign to you, because roger does something very similar on fadedpage. (he lists the words, and makes users copy each one of 'em into the bulk-add box, but other than that, it's the same.)
Generally, I find little that is intuitive about the interface; however, this is not surprising, as I think there is very little in the world that is truly intuitive.
i wasn't aiming at "intuitive". "easily-explained" is good enough.
You might want to add some page title and explanatory comments to make it clear that the page consists of two parts
thanks, but no. once the system has been "easily-explained", those elements just become unnecessary clutter to the user...
In order to reduce "noise," you may want to have two separate pages, with a "switch mode" button to switch between "smooth reading" mode and the "edit" mode.
considered that. but decided to do it this way instead. maybe once the interface-experimenters discover gold, and have a nice ajax thingee that makes everyone happy, i'll use that. in the meantime, i'll "keep it simple, stupid".
I assume that for editing you would like people to use your proprietary s.m.l. markup language.
um, it's "z.m.l." the "z" stands for "zen", remember? and "zero" and "zip" and "zilch" and "zoo" and "zzz". and it's kind of silly to call it "proprietary", since anyone can invent their own light-markup format, including one that's just like z.m.l., and i will only cheer them on from the sidelines, very raucously...
It would probably be a good idea to add a button and associated popup window with a s.m.l. "cheat sheet."
i'll be doing something like that, yes...
Hope this helps. Good luck.
aside from some unnecessary spin there at the end, it was honest feedback, and i thank you for offering it. it was definitely worth it to pull it from the spam folder. -bowerbird

On 3/30/2010 12:08 PM, Bowerbird@aol.com wrote:
ok, do i dig lee's post out of my spam filter, or not?
decisions, decisions, decisions... ;+)
***
lee said:
On my system, my browser window is approx 1050 x 1600.
oh lordie.
you make your interface work for the average case, and who reports back? the people who are _not_ average, that's who.
I would argue that one of the most important lessons of the internet is that there is practically no such thing as an "average" user. One of the beauties of well-constructed HTML is that it accommodates itself to /all/ users, not just the mythical "average" user. If you ever come across a web site where you have a right/left scroll bar (and there are many) you know you have encountered a web designer who's stuck in the desktop publishing world.
a 1050*1600 browser-window is a _portrait_ viewport...
are you really using a portrait monitor, lee, or are you just being perverse by arranging your browser-window that way?
Actually, I have two monitors, side-by-side, both rotated into portrait mode. As a programmer, I find I need to see as much code as possible, top to bottom, to grasp the flow of a program, particularly when using a symbolic debugger and significant portions of the window are consumed by watches and stack traces. As I do a lot of client/server programming, I will frequently use one monitor for my development environment and debugging, and the other will be a remote view of the other machine I'm working with. While I can stretch a window across the two monitors, if I maximize a window in snaps to fill just one of the monitors. [snip]
so i think lee and his portrait browser-window might well be having problems negotiating _any_ collaborative proofing site, not to mention almost any site at all these days, if we're real...
Yes, I have similar problems at the FadedPage site, although it's not quite as bad as they have only a single frame containing the page image. And I am finding that the problem is really coming down to the issue of being able to scale the image, not any of the surrounding controls. With a width of 1050 (the maximum resolution of my particular monitors) to reduce the text to a point where I get anything like the kind of layout you describe the text becomes so small as to be illegible; the reason is while I can reduce the font size I can't reduce the page image size, which is really about twice as large as it needs to be to be legible. If anyone has any suggestions as to how to dynamically resize images, I'm all ears, because this is one of the problems I'm going to need to resolve for my own co-operative proofing demonstration. If you want any screen shots of the various configurations I've tried, I'd be happy to e-mail them to you.
anyway, thanks to jim and lee for bringing up the issues that arise around the issue of screen-size (and screen orientation). i was (and am) continually aware of them, thanks to being very fortunate in having had a very big monitor for over 6 years, but it's good to have it reinforced. especially with the netbooks and the iphone/ipad, the range of screensizes is now overwhelming.
Yes. I think this is a critical observation. The variety of devices on the market today is such that no one configuration represents the majority of users. I have rather poor eyesight, so I always set my monitors to the highest possible resolution, then increase the scaling of my fonts to 130-150% of normal. One of my pet peeves is colleagues who assume everyone uses the same font size and as a result build input boxes which are too short for the intended input, or cause controls to actually appear outside of the visible boundaries of the windows. In building UIs, we all need to be more empathetic to the needs of the users who are not just like us. [snip]
there are two sets of radio buttons, one alternating between "b" and "c", and the other between "sho" and "no." I have no idea as to what these two sets of radio buttons accomplishes.
you could've tried them to find out. you know, curiosity. (that thing that killed the cat.)
or i can just tell you...
the b/c set stands for "button" versus "color". this controls the way that flagged words are displayed. the default is by "color", meaning that the flagged words are rendered in red. that makes them stand out, vividly, but it's all that that does.
These radio buttons don't seem to work at all with Firefox 3.5.8 on Windows XP.
i wasn't aiming at "intuitive".
"easily-explained" is good enough
Fair enough. In this case I think you need to include some sort of access to the easy explanation from the page itself. [snip]
I assume that for editing you would like people to use your proprietary s.m.l. markup language.
um, it's "z.m.l." the "z" stands for "zen", remember? and "zero" and "zip" and "zilch" and "zoo" and "zzz".
s.m.l. => Spousal Markup Language. So called, because while there are rules, one has to figure them out for oneself ("it's so obvious I shouldn't have to tell you what they are") and because they're so subtle that one can't really tell when they've been broken. :-)
and it's kind of silly to call it "proprietary", since anyone can invent their own light-markup format, including one that's just like z.m.l., and i will only cheer them on from the sidelines, very raucously...
Proprietary simply means "property of." You have invented the markup language, and I suspect you would take umbrage if someone else were to try and alter it. Anyone can use it, but you "own" it. It is thus proprietary. This situation is neither good nor bad, it's simply the way it is.

Am 31.03.2010 um 19:19 schrieb Lee Passey:
I would argue that one of the most important lessons of the internet is that there is practically no such thing as an "average" user. One of the beauties of well-constructed HTML is that it accommodates itself to /all/ users, not just the mythical "average" user.
If you ever come across a web site where you have a right/left scroll bar (and there are many) you know you have encountered a web designer who's stuck in the desktop publishing world.
I would very much disagree here. Because as you say there is no such thing as the standard user. Or a standard font of size for that matter. Sure you can define that certain fonts and sizes are to be used. Yet, does the user have them or what to use them. I agree with you in so far that the general design of a page should not require a scroll bar. Yet, it should show up if the setup a user has makes it necessary. My main machine is a 17" MacBook with the resolution pushed all the way up. At times I zoom pages or change the default sizes and then the pages go unusable. because scroll bars do not pop-up of the page is not designed very intelligently. As far as proofing is concerned, it is actually in the desktop domain and a web-based domain. So what is wrong with having scroll bars. They become more important in editing especial if you have multiple views in one window with different content. You resize the views to accommodate your needs and use the scroll bars when you need to reach parts you rarely need or use. I can remember when it was said you need to design your page for 640x480 resolution because other resolutions were not used that much. Or what you still find this page requires XXXX to display or display properly. Now that is poor design. regards Keith.

Hi Everybody, Joshua, Uhmmmm ! I do not think anybody would do proofing editing on a mobile divice, that is phones or PDAs. NetBooks most likely and probably the iPad. Whether a browsers supports a standard generally depends on the browser and not the device it is running on. regards Keith. Am 01.04.2010 um 23:29 schrieb Joshua Hutchinson:
I've had some luck using the CSS max-width
You can tell an img tag to max-width: 75% and it will resize the image to fit that much of the available area. It'll even dynamically resize when your stretch your browser window.
Downside: Some browsers *suck* at resize images. IE6 does not support max-width, though pretty much everyone else does on the desktop (haven't tested it with any mobile devices, though).
Josh
On Mar 31, 2010, Lee Passey <lee@novomail.net> wrote:
If anyone has any suggestions as to how to dynamically resize images, I'm all ears, because this is one of the problems I'm going to need to resolve for my own co-operative proofing demonstration.
_______________________________________________ gutvol-d mailing list gutvol-d@lists.pglaf.org http://lists.pglaf.org/mailman/listinfo/gutvol-d

I do not think anybody would do proofing editing on a mobile divice, that is phones or PDAs. NetBooks most likely and probably the iPad.
It would be nice to at least be able to SR on anything that allows input and have a standardized way to flag an error.
participants (5)
-
Bowerbird@aol.com
-
Jim Adcock
-
Joshua Hutchinson
-
Keith J. Schultz
-
Lee Passey