Otte: staring into the abyss
Otte: staring into the abyss
Posted Jul 28, 2012 8:32 UTC (Sat) by bojan (subscriber, #14302)In reply to: Otte: staring into the abyss by misc
Parent article: Otte: staring into the abyss
- It now takes more mouse moves/clicks to start an app, change a workspace etc. (not to mention complete lack of workspace visibility). To this Gnome 3 brigade responds with the baffling "use you keyboard" mantra. Huh?
- Users are attacked by unnecessary view changes for even the most trivial of actions, like starting an app. Regular desktop has plenty of pixels to overlay a menu without view change, unlike a smartphone. Gnome 3 brigade respond to this with even more baffling "you are being distracted by the menu and the taskbar" mantra. Double huh?
- It is impossible to do even the most trivial of customisations (e.g. removing an icon from the panel) without writing code or convincing someone to do it. Combinatorial explosion of extensions is mind boggling. To this Gnome 3 brigade respond with "this is progress" mantra. Completely lost by now...
So, it's not about "I don't like". It's about "simple things are more complicated now". These are called regressions.
Posted Jul 28, 2012 14:46 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (19 responses)
My biggest bug-bears are (1) being expected to use the mouse, and (2) bloody autocomplete! If I want to type "10 Jan 2012" I don't want to end up with the system recognising the year and giving me "10 Jan 2012-07-28"!!!
Don't forget. The whole point of being a touch typist is YOU DO NOT LOOK AT THE TYPEWRITER (or screen). If the computer is trying to be halpful it's going to mess you up something chronic. How many of you can outperform a touch typist?
Cheers,
Posted Jul 28, 2012 16:50 UTC (Sat)
by mpr22 (subscriber, #60784)
[Link]
Posted Jul 28, 2012 20:07 UTC (Sat)
by nix (subscriber, #2304)
[Link] (15 responses)
(OK, I know you can touch-type while e.g. reading something else... but generally one looks at the screen quite a lot when one is typing.)
Posted Jul 28, 2012 22:26 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (14 responses)
A trained typist does 120wpm (here w actually means 5 characters). So that's 10 characters a second SUSTAINED OUTPUT. How are you going to "context switch" between reading the text you're copying, and the output on paper or screen?
You may look at the screen a lot while typing, but a trained typist looks at what they're copying, not what they've copied. While I'm typing I mostly don't look at the keyboard. Okay, I look at the screen to make sure I haven't made a mistake, but the point of being a trained typist is that you don't make mistakes, so you don't need to check the screen to find them. As such, if the computer throws things up on the screen, it is a REAL nuisance - don't forget I said a trained typist AVERAGES ten characters a second...
Cheers,
Posted Jul 29, 2012 8:20 UTC (Sun)
by rschroev (subscriber, #4164)
[Link] (2 responses)
Sometimes when a coworkers asks me something, I look at them and keep typing, but then they think I do it just to show off. Which is true, partly.
I have to admit that I can't type without making mistakes, even though I've had some typing training (long ago). I make little mistakes when typing normal text like this comment, but it gets worse when I have to type a lot of non-alphanumeric characters, like when I'm writing code.
Posted Jul 29, 2012 12:49 UTC (Sun)
by Wol (subscriber, #4433)
[Link] (1 responses)
Something else I thought of, too - which is faster, to context-switch and take advantage of the computer's help, or to just carry on typing? If you're a fast typist, the computer "being helpful" is just getting in the way.
I play classical guitar, so I actually class myself as a 6-fingered typist, and typing this comment here it's actually quite obvious. I'm using my left hand "correctly" as a touch-typist and it's making almost no mistakes. My right hand is doing a two-fingered "hunt-n-peck", and making a lot of mistakes. So even if I don't have something to copy, autocomplete can be a real nuisance for me.
So yeah, for many of us auto-complete probably is helpful. But for someone who knows how to type, it's almost certainly faster and easier to turn it off (that is, you can find out how!) and do everything long hand - you'll do it faster than you can context switch.
Cheers,
Posted Jul 29, 2012 13:12 UTC (Sun)
by nix (subscriber, #2304)
[Link]
In the Emacs world, CEDET with auto-complete.el does this, displaying potential tab-completions in faint text beside the cursor after a short delay (when you've obviously stopped typing in the middle of an identifier because you can't remember what it is), and only on hitting, say, the tab key do you get an actual popup menu to select potential matches from.
I've seen IntelliSense systems that lack one or the other of these properties and they are both intolerable to use, either spamming you with stuff you already know, or popping up things and blocking user input when you don't want that.
Posted Jul 29, 2012 13:09 UTC (Sun)
by nix (subscriber, #2304)
[Link] (10 responses)
Now you might defined a trained touch-typist as a trained touch-typist only if they happen to be doing transcription or other copying at the moment, but I think that's a tiny bit restrictive. It is possible to do things with computer systems other than copying text. :)
Posted Jul 31, 2012 1:58 UTC (Tue)
by jzbiciak (guest, #5246)
[Link] (9 responses)
Others say they get dizzy if they try to watch.
So, while my eyes may be facing the screen, I'm not really seeing everything that I'm typing. And then there's plain text. Since my web browser routinely inserts 5-10 second pauses while I type, I often find myself looking away and thinking about what I'm trying to say rather than watching the herky-jerky nature of the text box.
I may not be a 120wpm professional secretary, but on timed typing tests I can pull 90-95wpm. I feel that's pretty respectable for an electrical engineer. ;-)
Posted Jul 31, 2012 23:05 UTC (Tue)
by nix (subscriber, #2304)
[Link] (8 responses)
I am willing to believe that my clinical coordination deficits make me a bad example though. Perhaps most people with typing training typo much less often than me, and can avoid looking at screens for long periods?
Posted Aug 3, 2012 11:48 UTC (Fri)
by man_ls (guest, #15091)
[Link] (7 responses)
Posted Aug 3, 2012 12:31 UTC (Fri)
by jzbiciak (guest, #5246)
[Link] (6 responses)
I guess it depends on the language and the nature of what it is you're writing. For what it's worth, I've typed most of this comment without looking at the text box. :-) It's just easier that way. I'll go back and read it before I hit submit.
As for code, it's more often true that I'm not really "seeing" my edits when I'm restructuring existing code, as to writing new code. I do structure my code visually a rather particular way, though, so that I can do quite a lot with my peripheral vision. So, I more half-see than see much of my code, but I do rely on sight pretty heavily. I'm one of these folks that lines things up religiously. Examples: Code like that I can often whip out while only half-looking at the screen.
Posted Aug 4, 2012 12:37 UTC (Sat)
by nix (subscriber, #2304)
[Link] (5 responses)
Posted Aug 4, 2012 16:45 UTC (Sat)
by jzbiciak (guest, #5246)
[Link] (4 responses)
Actually, I find your compressed whitespace version harder to follow, probably because I'm in the habit of moving my eyes between columns and working fields in groups. I'll read a few field names (as in 2 to 4), then jump to the column of values, then back to the column of field names, etc. That is to say, my visual scanning is roughly like this:
...followed by... All three values are centered together in the highest-res portion of my vision. That doesn't work as well when the second target is more like: If it makes sense to do so, I'll even insert a blank line to make the grouping more obvious, or use different horizontal columns for the values in the groups, if the groups are more logically separate.
If I always scanned field name by field name one at a time, it'd be a problem. But since I tend to bunch fields in logical groups, and tend to treat them as groups, it's actually easier for me to follow when I can see all the field names simultaneously, and then see all the field values simultaneously. My brain can remember field order for a handful of fields at a time, and so treating them in groups goes much faster for me.
Now, in C++, where all those fields would be constructor arguments instead, I'd probably group them differently. In any case, I try to group things to that my innate visual sense of "alike" and "different" help me spot anomalies.
In your compressed version, I have to play "find the value", and I forget what value I'm looking for after awhile. I'm forced to read field-by-field, which is much slower for me. I'm /less/ likely to find unintended discrepancies.
I guess it's the same reason I write "max" with this idiom:
It's easier to see I've hooked everything up properly if I can read down the columns and everything reads in the same order in each column. BTW, on the tabs thing: I've got a strict no-tabs policy in our team, and we set indentations at 4. It's easily enforced so far, though, because there's no more than a few of us at any given time. We're attached to a chip design team, so there's no danger of us suddenly growing our software team...
Posted Aug 5, 2012 7:27 UTC (Sun)
by dirtyepic (guest, #30178)
[Link]
Posted Aug 6, 2012 8:30 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
I've never worked on anything like that (I started out on financial database stuff, then as soon as I started working for a major database vendor I stopped working on databases and started working on stuff closer to the toolchain), and would consider heaps of simple assignments bunched together like that tantamount to lack of sufficient ingenuity: it's usually unnecessary code, since it's normally right next to the declaration anyway. So as long as it's something C would permit in an initializer, I'd probably use one (a designated initializer if necessary). Inside designated initializers, which are certain to contain a group of closely related initializations, I often *do* line things up as you suggest, as long as the amount of introduced whitespace is low -- so I think perhaps there is less difference between our coding styles than was at first visible.
My rule is simple: avoid the boring and evil (one is hard to write: the other is hard to read). What is boring to me is that repeated-over-and-over 'stic->' in your example: what is evil is a spaced-out initializer with a lot of space in which the eye gets lost. (Your solution there would probably be to group them differently so that variables with names of similar lengths were grouped together: mine would generally be to not space them out. I can't really call this a huge difference in style.)
In any case, there is one situation where spacing-out is always called for: same-line comments. *Nobody*, not even weird people who voluntarily use Hungarian notation, puts all their same-line comments right next to the code it describes unless the line is long. And not even in these days of 200-column xterms does anyone write a 200-column same-line comment.
My apologies for not turning this into a dark-curse-ridden my-way-or-/dev/null flamefest. I'm aware that I am below quota on these for this year and will lose my Internet access privileges unless I get some better flame up.
Posted Aug 6, 2012 13:02 UTC (Mon)
by jzbiciak (guest, #5246)
[Link] (1 responses)
In Pascal, I could have used a "with" block, but C lacks such things. In perl, I use the fat comma in a nicely indented initializer block: The particular code I shared earlier (the STIC code) actually largely pre-dates wide availability of C's designated initializers. With a modern C compiler I would instead consider putting initializers like that block into const structures and use structure assignment to copy the block in in one go. That would both eliminate the boring repeated prefix, and would also likely reduce the overall code footprint since it would replace the discrete scalar assignments with a loop.
Posted Aug 6, 2012 13:58 UTC (Mon)
by nix (subscriber, #2304)
[Link]
Posted Jul 29, 2012 3:22 UTC (Sun)
by bojan (subscriber, #14302)
[Link] (1 responses)
I never said that making Gnome 3 work better with keyboard only was a bad thing. What I said was that making Gnome 3 work worse with the GUI/mouse was a bad thing. Pointing out to people that they can use the keyboard instead of GUI/mouse is completely beside the point. A distraction, really. As if they couldn't do it in Gnome 2 already.
PS. I would really like to know how your touch typist would read the screen without looking at it. Surely, there must be things of interest on the screen beside what this wonderful typist wrote. :-)
Posted Jul 29, 2012 13:02 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
Actually, I don't use Gnome3 at all - don't remember even seeing it! My gentoo make.conf has USE=-gnome in it.
I'm very much "each to their own" so if people like (or hate) Gnome, I don't care. I don't like it, I don't use it, that's my choice FOR ME.
Point is, I picked up comparing keyboard and mouse - I find all too often I'm pushed towards using the mouse, which I hate. The OP I responded to didn't seem to care for the keyboard, which pushed my buttons :-)
As for your PS :-) I'm also a WordPerfect fan. One of its design aims was to "look like a piece of paper" - there's NOTHING on the screen apart from what the typist wrote :-) After all, isn't that the typist's job - to convert what they've been given - audio, hand written notes, someone else's copy - and convert it to text in a computer file? What concerns them is the input - it's just assumed the output will be accurate.
That is one of the reasons MS Word is so dire - it's aimed at the *novice* typist and makes their life easy. No problem with that, except that it is marketed as "for everyone" but it most definitely is NOT a professional tool - all its "help the novice" features seriously impede professional productivity (and can be difficult to disable! :-(
Cheers,
Otte: staring into the abyss
Wol
Better (faster, easier to remember, whatever) keybinds? Good. More clicks per operation for mousers: Bad. Very bad indeed. (And I say this as a keyboard fan.)
Otte: staring into the abyss
Otte: staring into the abyss
The whole point of being a touch typist is YOU DO NOT LOOK AT THE TYPEWRITER (or screen)
Touch typists don't look at the screen? Huh?
Otte: staring into the abyss
Wol
Otte: staring into the abyss
Otte: staring into the abyss
Wol
Otte: staring into the abyss
If you're a fast typist, the computer "being helpful" is just getting in the way.
That's why IntelliSense-class 'helpful' things should obey two rules: operate on a customizable delay, and don't pop up things that change the semantics of input unless explicitly requested.
Otte: staring into the abyss
Otte: staring into the abyss
Otte: staring into the abyss
Can't see how. I can imagine prose writers typing along by heart; the legendary Asimov comes to mind -- and his prodigious output is witness. But for code I don't know anyone who can write by heart. As has been said above, structure and context are crucial. Perhaps a more textual language might do the trick, and bring along miraculous productivity improvements... I think I prefer a more concise language, even at the cost of indentation marks.
Otte: staring into the abyss
Otte: staring into the abyss
/* Calculate bit_r 8-bit bit-reverse table */
for (i = 0; i < 256; i++)
{
uint_32 bit_r = i;
bit_r = ((bit_r & 0xAA) >> 1) | ((bit_r & 0x55) << 1);
bit_r = ((bit_r & 0xCC) >> 2) | ((bit_r & 0x33) << 2);
bit_r = ((bit_r & 0xF0) >> 4) | ((bit_r & 0x0F) << 4);
stic_bit [i] = i << 8;
stic_bit_r[i] = bit_r << 8;
}
...
stic->stic_cr.read = stic_ctrl_rd;
stic->stic_cr.write = stic_ctrl_wr;
stic->stic_cr.peek = stic_ctrl_peek;
stic->stic_cr.poke = stic_ctrl_poke;
stic->stic_cr.tick = stic_tick;
stic->stic_cr.reset = stic_reset;
stic->stic_cr.dtor = stic_dtor;
stic->stic_cr.min_tick = 57; /* to get started. stic_tick will reset. */
stic->stic_cr.max_tick = 57;
stic->stic_cr.addr_base = 0x00000000;
stic->stic_cr.addr_mask = 0x0000FFFF;
stic->stic_cr.parent = (void*) stic;
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->stic_accessible = 0;
stic->gmem_accessible = 0;
if (stic->req_bus)
{
stic->req_bus->intak = ~0ULL;
stic->req_bus->intrq = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->next_busrq = ~0ULL;
stic->req_bus->next_intrq = ~0ULL;
}
Yep. And code like that is great if the data you are entering is really columnar. It's awful for e.g. the very assignments you show it used for, becaue it's actually quite hard for the eye to track from, say, one of those = 0's back to the thing you're assigning to -- you have to track across a lot of whitespace without deviating horizontally, which the eye is notably bad at. In this specific case it doesn't matter because the assignments are all either of 0, or at the end of a block, or of a name similar to the name of the variable, or there happens not to be much whitespace, but can you see how bad this close variant is? (reordering things to provide an example with enough horizontal whitespace to make my point, I know this makes no sense as code anymore):
Otte: staring into the abyss
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq = 0;
stic->stic_accessible = 14;
stic->gmem_accessible = 0;
It's actually quite hard to see which variable that 57 or 14 are assigned to: they're lost in a sea of horizontal whitespace, while the columnar format makes it appear that all those 0s and 14s and 57s are related to each other, when they are not at all. Isn't this clearer?
stic->phase = 0;
stic->next_phase = 57;
stic->fifo_ptr = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq_until = 0;
stic->req_bus->intrq = 0;
stic->stic_accessible = 14;
stic->gmem_accessible = 0;
Another problem with lining things up like you suggest is that it encourages people to use tabs to line things up, rather than restricting themselves to using tabs solely in the left margin as sole indentation mechanism. And I don't need to tell you why that is an awful idea unless you have a way of enforcing that absolutely everyone on the project uses the same tab size. (I prefer to do as GNU is increasingly doing and simply ban tabs outside of literal strings. It's too easy for a thoughtless co-worker with the wrong tab size to turn a codebase into mush with a single save when tabs are in wide use. With spaces, this is impossible, even if you do lose the easy 'change the indentation by changing the tab size' trick. This trick rarely works in practice because most people don't have the discipline to use tabs and only tabs as indentation mechanism, with no padding out with spaces, and to use them nowhere else, ever.)
Otte: staring into the abyss
stic->phase
stic->next_phase
stic->fifo_ptr
= 0;
= 57;
= 0;
= 0;
XXXXX = 57;
XXX = 0;
if (max < val)
max = val;
Otte: staring into the abyss
Otte: staring into the abyss
Otte: staring into the abyss
My rule is simple: avoid the boring and evil (one is hard to write: the other is hard to read). What is boring to me is that repeated-over-and-over 'stic->' in your example: what is evil is a spaced-out initializer with a lot of space in which the eye gets lost.
my %hash =
(
foo => 0,
bar => 42,
baz => 1,
quux => 1234,
gronk => 0
);
Otte: staring into the abyss
Otte: staring into the abyss
Otte: staring into the abyss
Wol