if the tables were turned and M$ had only 5% and Linux had 90% of the users out there you can bet we'd be seeing viruses/trojans/worms and hacks coming from all over the place
No, that doesn't follow.
You can bet there'd be people trying to write viruses/trojans/worms/&c. But size of userbase isn't the only factor here; some OSs are far easier to break into than others, and that'll also have an effect. So will the number and organisation of people supporting it, and the way that bugs and fixes are managed and distributed.
Whether virus writers will succeed in creating something nasty, whether the result spreads widely, and whether the hole is plugged quickly and effectively, all depend on those other factors. So far Windows seems to have a far worse record on these things than most other OSs, and they won't change much with popularity.
The Series 5mx is still quite a nice machine despite its age. It meets many of your requirements, handling plain text, Palm DOC, PDF, HTML, Mobipocket, TCR, TomeRaider, and other formats, via various apps.
Display is 640x240, which is enough, and you can install any fonts you like. It's only greyscale, but as you say, that's fine for reading text. It does have a nice backlight, though, which is great for reading in bed!
It takes AAs instead of having an inbuilt rechargeable, but that's how I prefer it -- if you want to use rechargeables, you can use any form of AA rechargeable you like. You can use a standard power adapter too. And if you're away from wall sockets for any length of time, you can take spare AAs, or even buy them. I've had enough bad experiences with proprietary batteries running out away from home, that I value that! I generally get 10-20 hours' use, but then I'm a power user, and just reading books should give much more.
It also doesn't have USB, but that's not really a problem for me. My Mac has a CompactFlash reader, so I pop the CF out of the 5mx and into the reader, and it mounts as a drive on the desktop. Great for backups and file transfers. As to capacity, it has 16MB of built-in memory, but you can get CFs over 1GB now, and if you can fill that with text I'd like to see it.
And since the same few objections get posted every time someone mentions ebooks:
No, no-one's claiming ebooks will replace paper completely.
No, we don't care that you don't like them.
Yes, we still like them anyway.
Of course paper has some advantages, but ebooks have others, and they'll balance differently for different people. For me, I find the convenience of always having reading material in my pocket means I do most of my reading on the 5mx.
Oh, and while I'm here, a quick unsolicited plug for Fictionwise as a good place to get texts. It's a shame that most of their latest stuff is DRMed, but they have a lot of good unrestricted stuff too.
Consistency is so important to find your way around code. I've spent so long being confused by different names that eventually turn out to be referring to the same thing, and one name used to refer to several different things... Yes, this matters in comments as well as identifiers.
OTOH, I've tried a couple of standard prefixes, and come to hate them. Scope prefixes can be slightly useful; they tell you where to go to find out anything else. (Depends on the language/system.) But IME type prefixes are awkward, long-winded, and give no benefit. If you can see the variable name anywhere, then you've usually got about as much information as you need to use it. And of course encoding the type precludes you from changing it -- it only takes one or two variables which have been retyped but not renamed to put you off! But I know people feel differently about this, and I don't want to start a Holy War on what's really a minor point compared to the vast amount of really bad code being written...
Your point 2) is I think an application of a more general principle: concentrate on success. Of course, failures must be spotted and dealt with, but the main flow of the code should always be with the successful case(s). Not only does it make cases like you describe easier to handle, it also helps you to think about what the code is really doing.
I'd like to qualify 3) a little: the lengths of identifiers should generally be directly proportional to their scope. Globals (which are of course EVIL anyway) are doubly bad when you can't tell what they mean. But I've also seen code which is made completely unreadable by having short-term index variable with 10 or 20 characters. I'd be perfectly happy with a variable called 'i' if it was only used for a few lines, and the context made its value perfectly clear; though maybe 'cell' or 'line' or something might be even better. The knack with naming is to find the shortest name that's meaningful in the circumstances.
And comments are similar. For goodness' sake, DON'T put comments in to explain stuff that's obvious from the code. (This very day I've been working on code with lines like:
indent = *(bufStart + i * 8 + 4)// Set indent
...!) And DON'T use comments to explain bad code when you could write better code which didn't need the comments.
Instead, write comments to explain the big picture. I'm not stupid; I can usually work out what the code is doing at a low level. What I have more trouble seeing is why it's doing that, and how it fits in with the rest of the system. And explain functions/methods/procedures from the caller's point of view. If I want to see how it works, I can; but if I'm going to be calling it, I need to know what assumptions to make, and what it can do for me.
Java is a platform -- it has a specification, and Sun's own implementation. Which are we talking about here?
At present, anyone can build a clean-room implementation of the Java specs; if it passes Sun's compatibility suite, then you can call it 'Java' and do what you like with it. I'd say that's pretty open already.
What more could be done? Well, one thing is to open up the specification. Sun already accepts outside input to that, via the JCP; any further would probably mean dropping the compatibility requirements, and letting anyone call anything 'Java'. A Very Bad Move(tm)! We'd get lots of competing 'Java' platforms that were all incompatible with each other, no-one would know what to write for, and it would kill the language.
The other thing is for Sun to open-source their own particular implementation. That would have several good effects, e.g. much easier porting to other platforms, fixing of bugs, optimisation, &c -- but they'd have quite a job to ensure that the results still had to pass their compatibility suite. (Or, again, chaos would reign.)
One final thing: Java gets a very biased press on/. If you believed what you read here, you'd think no-one used it, that it had died a death, that it never ran beyond a crawl, and that it epitomised everything that was bad about closed standards in comparison to the wonderful openness of C#. But that's all rubbish. In the real world out there, it's about the highest-demand skill; it's behind a staggering amount of development in the corporate, commercial world; implementations have come an awful long way in the last few years; and the platform as a whole is far more open than C# will ever be. I think it merits a place on the 'Reports Of My Death Have Been Greatly Exaggerated' list, alongside BSD and Apple...
What's wrong with having #ifdef, #define or some other kind of compile directive?
Two main things.
The generic any-language answer is that a pre-processor is awkward, fragile, and ugly. It's parsed, processed, and structured differently from the code -- it has different tokens and different semantics; it can lead to code that's a nightmare to maintain, and makes automatic source processing much harder.
And the Java-specific answer is that, as the parent says about 'goto', there are better ways to do any of the things you might want a preprocessor for:
Probably the main one is to work around different compilers, OSs, architectures, and platforms. But Java is one platform; if you need to do something that different on each underlying OS or system, then you're doing something wrong!
Another reason is isolation of constants and other singletons (is that what you mean by your comment about 'login'?); but Java has better ways to handle these (class constants, static finals, singletons, &c).
A third reason is optimisation; but that's the sort of thing that a dynamic compiler can probably decide better than you can, especially given that your code may run on different JVMs with different characteristics. (Some 'optimisations' made to early Java code actually slow it down when run on more recent dynamic JVMs.)
A fourth is conditional compilation for assertions or other development aids; again, you can do this more neatly with a simple 'if' statement -- and a decent compiler or runtime will optimise it away when not used.
In short, there are no reasons for a preprocessor in Java, and lots of reasons against.
Okay, we'll do that if you open-source folks stop claiming you have drop-in replacements for many expensive apps that are "just as good, honest"...
Seriously, no one's claiming that the GIMP is no good to anyone. Nor that it's not a decent achievement, nor that it might not be the best value-for-money for many folks.
But if open source software is to live up to some of the hype that its own community generates, then it should also stand some comparison on merit, regardless of cost.
In some cases, it does -- LilyPond, for example, delivers the best-quality music engraving I've seen on any consumer package, better than what I've seen of Sibelius, and certainly better than my copy of Cubase (which excels at other things, of course). And of course, we all know how well it does at OS-level and similar software. In other cases, it's near enough for many people.
But if we're going to take the attitude that "It's free, so it doesn't need to be much good", then we're falling far, far short of our potential.
these Photoshop users are used to photoshop. Any other UI no matter how slick and perfect will be worse for them.
That's certainly one explanation for why many experienced Photoshop users don't like the GIMP when they see it.
But it doesn't explain why some experienced GIMP users prefer Photoshop when they see that -- as reported in other comments. Nor why some users dislike the GIMP without having seen Photoshop. So that's not the only factor; maybe not the major one.
I've said it before, and I'll say it again: we're not all UI experts, but we can all improve. IMO that's the main problem with the UI of many packages -- not that developers don't have the UI skill so much as they don't care.
Half of UI design is simply forgetting what you know about computers in general, and your bit of software in particular. You'd think it'd be easier to forget than to learn! You just have to step back and ask questions like: what's the user trying to do here? What mindset will they start off with? What will they expect? How can we make it easy for them? How little do they need to learn to do it?
Yes, sometimes coming up with the right UI will involve lots of UI experience, having learned techniques and tools, or having that mindset. But I reckon half the time it's simply down to caring about the UI, stopping for a moment and asking whether this whizzy bit of code you're keen on is really the best thing for the user, or whether something simpler or less clever will be better.
The other thing you need is discipline. Sometimes providing two different ways to do something is worse than just providing one, especially if neither do it properly. Sometimes you need to keep things simple and uncluttered -- having to shoe-horn stuff together that doesn't naturally fit is often a sign of deeper problems in your underlying model. Sometimes you need to restrict what your users can do. After all, it's better to do one thing really well than several things badly. And sometimes you need to respect platform/system/community standards, even if you don't like them.
As usual, I've rambled too long. But if all developers cared about their user interfaces, and had the discipline to do what was needed, then all software would benefit.
Perhaps I should explain the concept of an 'etymology'... The part you've highlighted explains the origins of the word -- it's showing you how we got the word in the first place, not its current meaning.
My dictionary (Concise Oxford) notes that this stressed form of 'to' has been spelled 'too' since the 16th century. Ever felt behind the times?
But ripping as one long track means you lose all the other per-track fields. It means you can't transfer just a few tracks to a player or whatever. It means you'd have to re-rip everything. Much more awkward in many ways.
If you're going to add in extra information from somewhere, surely it's better to keep individual tracks and add in just the exact length; that way, players should be able to tell exactly when to stop playing and move on to the next track seamlessly. Should be a much simpler change, and degrade more gracefully.
I expect it's to do with the way that sound is split into frames for encoding. Maybe the format assumes that the sound will fill a whole number of frames, so there's no way of telling that the sound stops half-way through the last frame?
Even in that case, though, it shouldn't be too hard for the software to see that the sound stops abruptly half-way through the last frame, and infer the endpoint?
Not a perfect solution, by a long way. Sometimes it gives a gap; sometimes it truncates tracks; and even when it gets the timing right, there's usually a click or fluctuation in volume between the two tracks. And that's without using the 'Sound Check' feature, which screws it up further.
And of course even that partial solution isn't available on the iPod.
Being able to merge tracks together on import is great for a few specific situations, but it's not a general solution either. What if you want to keep the individual track index points? Or the titles, artists, and other information? (Many of my CDs have continuous music, and I don't want to rip each CD as a single track!) What if you've already ripped, or got the tracks from elsewhere?
Why is seamless playback so long in coming? I'd have thought it was a no-brainer. And it can't be that hard to implement, surely.
Oh, absolutely. But I don't think this works the way around you expect. I don't want to have to choose which quarter of my music collection to put on my iPod!
This is silly. Passwords should be one of: lengthy, frequently changed, unique across many systems, assigned by the system, or full of symbols and digits.
Insisting on more than one of those simply makes passwords impossible to remember, so of course people will write them down &c -- making them less secure, not more.
(I get round that by storing them on my Psion. In a password-protected file! Though with my Psion permanently within reach, that's not so much of an issue.)
I think you've hit the nail on the head there. While device drivers, consistency, ability to run popular apps, ease of installation, &c &c &c, are all reasons why Windows got popular, right now it's popular simply because it's popular.
That's what people know, so that's what people use, for better or worse. People don't know that there are alternatives; they don't want to change from one email app to another; they don't know people who'd help them; they don't know if there are apps on other platforms for doing what they currently do; they don't know if all their hardware will be supported; they don't know if and they worry greatly about file compatibility.
Some of these concerns are justified; some are not. But the biggest concern underlying these is fear of change. To get people to switch, you have to provide benefits outweighing that fear. These benefits may be killer apps, greater security, greater ease of use, lower cost, inertia (if something else is pre-installed on a new machine)... currently Linux has some of these, but falls down on others. Mac OS X falls down on different ones. But nothing completely outweighs that fear at the moment. And while fear of change is there, Windows will continue to be popular for no better reason than that it's popular.
I think this is one of the biggest problems with open source software usability. Part of what makes Mac OS X and Windows so easy to use is their consistency -- things generally work the way you expect them to. Yes, it's true that individual applications occasionally have special requirements that mandate something else, but this is far rarer than many developers think. It's easy to think, whether consciously or not, "This app is far too important (or I'm too important/intelligent/creative) to be bound by these boring conventions", when a bit more thought could find a solution which is consistent and good for your app. The result is that every app goes its own way to some extent, and that the entire platform loses out as a result.
I propose the following rules for breaking a common UI convention:
Don't Do It. Your app isn't as unique as all that.
If you have a good reason for it, Don't Do It anyway. See Rule 1.
If you have a very good reason, then think about it for a week. Try to get round the problem some other way.
If you can't, then write a 2000-word apology for why it's necessary. If you can't, or can't be bothered, Don't Do It!
Of course, this rather assumes you can determine what the convention is to begin with -- not always easy with open source...
Indeed. Concept albums and others where there's a unifying theme or style lose something if played in bits. (But ripping as one long track has its own problems.)
And what about albums like The War Of The Worlds, where there's continuous music throughout? Actually, quite a good number of my CDs are like this, and dropping in and out is extremely jarring. There's a similar problem with live albums.
And at the other end of the scale are many of my classical CDs (again, a good number) -- a single short movement of a work just isn't enough.
And what about compilations and mix CDs which have a number of songs sequenced with cross-fades?
Not to mention the fact that with as many varied styles and genres as I have, jumping straight from metal to spoken word to folk to funk to soundtrack to synth pop to instrumental can be extremely jarring.
IMO, if shuffle by track works for you, then you either have a very limited collection, or no taste!
most kids don't have a desire to learn these things
That's a real pity. I think most children tend to like learning generally -- that's what they're wired up to do. If they don't want to learn these things, then that's because they're being taught badly, or motivated badly, or something else is preventing them. That's the problem.
Basic math and basic english should be the primary goals of school. The other classes are simply a complete waste of time and only harm a person by preventing them from doing as well as they would have done if they focused on the basics.
Hmmm. So the aim of education is:
To teach skills that are likely to be of direct use in life generally.
Well, that's a laudable and valuable aim, certainly, but there others I can think of:
To teach general problem-solving and research skills, so that when people come across problems they've not learned to solve directly, as they will, they can work out or find out the solution.
To teach skills that are likely to be of direct use in employment. (Though this one is less important than many employers seem to think...)
To get children thinking about the world around them.
To bring awareness and appreciation of subjects and areas of knowledge that they've not been exposed to, so that they can explore them further if they wish. For example, many children may not otherwise get any real exposure to classical music -- some won't enjoy it much, of course, but some will, and that pleasure can last the rest of their life. The same applies to many other subjects. How can you get interested in science, say, or history, or the classics, if you never hear any of it?
I'm not decrying the teaching of basic maths and English -- they are probably the most important skills, and over the last generation have often been taught extremely badly. Standards of both are lamentable in far too many people.
But shouldn't education aim even higher still? Shouldn't it try to balance all of these aims to some extent?
Just what exactly gives you the right to use the software?
You don't need to be given that right; you have it already. The general situation is this:
By default, you have every right to use software. (No law prevents you.) EULAs (try to) take away some of that right.
By default, you cannot distribute software. (Copyright law prevents you.) The GPL can give you that right.
So nothing's stopping you from using GPLed software, even if you don't accept the GPL. However, you must accept the GPL in order to distribute it, because otherwise you wouldn't have that right.
Open Source folks freely give license for you or anyone else who cares to modify, use, change -thier work- for your use.
With only the restriction that they can keep the right to what they created.
Yup, shame on them for not considering the needs of the entire rest of the world.
Yes, that's true and a valid PoV.
But we're talking about software quality here. Doesn't open source software compare well to closed-source on merit? Or do we need to excuse its technical shortcomings on the grounds of its philosophy?
Oh yes, very true. More people should realise this. But I think many people could be a bit better at it than they are, if they put a little thought into it. Ego is one problem -- as the parent says, programmers often code for bragging rights, so they want their work to be seen. But a good UI is often not seen; it gets out of the way so that people can actually use the software. If programmers tried a little harder to think of their users, and what the users are trying to do, then I think things would improve.
(And I can't resist a little rant here about skins. IMO, a good UI should be elegant and simple, and not need skins. As such, skins are a tacit admission of bad UI design.)
I'm fairly lucky in that most of the OS software I've written has had me as a user. That gives valuable insight into what the software is there to do, and keeps me focused on the right things. It also lets me use trial and error over reasonable periods of time to see what works, as well as getting feedback from users.
The main lesson is that simplicity, elegance, and consistency are vital. Not just at the level of widgets or whatever, but (even more so) in the mental models and ideas behind it all. If you get the right abstractions at the heart of the software, then the UI and everything else are much, much easier to get right.
Oddly enough, I had a Jaz for several years, and never had any problems with it. I had one of the Jaz disks collect rather too many bad sectors, but I don't think I actually lost any data on it, and never heard any untoward noises. And I gave it a fair workout, too -- not just backups, but live data, and I did audio recording on it too. Not that I'm belittling folks who did have real problems, just that not all Jaz gave problems. Maybe things were better here in the UK, I dunno.
But yes, as everyone else has said, Iomega seem to be living in a dreamworld. Back when floppy was outdated and everyone expected a 'son of floppy' to become 'the standard', they had a chance; but now, people are so used to using CD-Rs and DVD-Rs for backups, and flash and USB drives for transferring files, this seems to be a pointless exercise.
In particular, this new one includes the drive motor and heads in the cartridge. So what's in the drive unit? And how are these cartridges any different from bog-standard IDE HDs? Other than the size. And that HDs are known to be reliable, steadily decreasing in price and increasing in capacity, portable between machines, and a standard...
Slashdot Mirror
No, that doesn't follow.
You can bet there'd be people trying to write viruses/trojans/worms/&c. But size of userbase isn't the only factor here; some OSs are far easier to break into than others, and that'll also have an effect. So will the number and organisation of people supporting it, and the way that bugs and fixes are managed and distributed.
Whether virus writers will succeed in creating something nasty, whether the result spreads widely, and whether the hole is plugged quickly and effectively, all depend on those other factors. So far Windows seems to have a far worse record on these things than most other OSs, and they won't change much with popularity.
Display is 640x240, which is enough, and you can install any fonts you like. It's only greyscale, but as you say, that's fine for reading text. It does have a nice backlight, though, which is great for reading in bed!
It takes AAs instead of having an inbuilt rechargeable, but that's how I prefer it -- if you want to use rechargeables, you can use any form of AA rechargeable you like. You can use a standard power adapter too. And if you're away from wall sockets for any length of time, you can take spare AAs, or even buy them. I've had enough bad experiences with proprietary batteries running out away from home, that I value that! I generally get 10-20 hours' use, but then I'm a power user, and just reading books should give much more.
It also doesn't have USB, but that's not really a problem for me. My Mac has a CompactFlash reader, so I pop the CF out of the 5mx and into the reader, and it mounts as a drive on the desktop. Great for backups and file transfers. As to capacity, it has 16MB of built-in memory, but you can get CFs over 1GB now, and if you can fill that with text I'd like to see it.
And since the same few objections get posted every time someone mentions ebooks:
- No, no-one's claiming ebooks will replace paper completely.
- No, we don't care that you don't like them.
- Yes, we still like them anyway.
Of course paper has some advantages, but ebooks have others, and they'll balance differently for different people. For me, I find the convenience of always having reading material in my pocket means I do most of my reading on the 5mx.Oh, and while I'm here, a quick unsolicited plug for Fictionwise as a good place to get texts. It's a shame that most of their latest stuff is DRMed, but they have a lot of good unrestricted stuff too.
Consistency is so important to find your way around code. I've spent so long being confused by different names that eventually turn out to be referring to the same thing, and one name used to refer to several different things... Yes, this matters in comments as well as identifiers.
OTOH, I've tried a couple of standard prefixes, and come to hate them. Scope prefixes can be slightly useful; they tell you where to go to find out anything else. (Depends on the language/system.) But IME type prefixes are awkward, long-winded, and give no benefit. If you can see the variable name anywhere, then you've usually got about as much information as you need to use it. And of course encoding the type precludes you from changing it -- it only takes one or two variables which have been retyped but not renamed to put you off! But I know people feel differently about this, and I don't want to start a Holy War on what's really a minor point compared to the vast amount of really bad code being written...
Your point 2) is I think an application of a more general principle: concentrate on success. Of course, failures must be spotted and dealt with, but the main flow of the code should always be with the successful case(s). Not only does it make cases like you describe easier to handle, it also helps you to think about what the code is really doing.
I'd like to qualify 3) a little: the lengths of identifiers should generally be directly proportional to their scope. Globals (which are of course EVIL anyway) are doubly bad when you can't tell what they mean. But I've also seen code which is made completely unreadable by having short-term index variable with 10 or 20 characters. I'd be perfectly happy with a variable called 'i' if it was only used for a few lines, and the context made its value perfectly clear; though maybe 'cell' or 'line' or something might be even better. The knack with naming is to find the shortest name that's meaningful in the circumstances.
And comments are similar. For goodness' sake, DON'T put comments in to explain stuff that's obvious from the code. (This very day I've been working on code with lines like:
Instead, write comments to explain the big picture. I'm not stupid; I can usually work out what the code is doing at a low level. What I have more trouble seeing is why it's doing that, and how it fits in with the rest of the system. And explain functions/methods/procedures from the caller's point of view. If I want to see how it works, I can; but if I'm going to be calling it, I need to know what assumptions to make, and what it can do for me.
At present, anyone can build a clean-room implementation of the Java specs; if it passes Sun's compatibility suite, then you can call it 'Java' and do what you like with it. I'd say that's pretty open already.
What more could be done? Well, one thing is to open up the specification. Sun already accepts outside input to that, via the JCP; any further would probably mean dropping the compatibility requirements, and letting anyone call anything 'Java'. A Very Bad Move(tm)! We'd get lots of competing 'Java' platforms that were all incompatible with each other, no-one would know what to write for, and it would kill the language.
The other thing is for Sun to open-source their own particular implementation. That would have several good effects, e.g. much easier porting to other platforms, fixing of bugs, optimisation, &c -- but they'd have quite a job to ensure that the results still had to pass their compatibility suite. (Or, again, chaos would reign.)
One final thing: Java gets a very biased press on /. If you believed what you read here, you'd think no-one used it, that it had died a death, that it never ran beyond a crawl, and that it epitomised everything that was bad about closed standards in comparison to the wonderful openness of C#. But that's all rubbish. In the real world out there, it's about the highest-demand skill; it's behind a staggering amount of development in the corporate, commercial world; implementations have come an awful long way in the last few years; and the platform as a whole is far more open than C# will ever be. I think it merits a place on the 'Reports Of My Death Have Been Greatly Exaggerated' list, alongside BSD and Apple...
Two main things.
The generic any-language answer is that a pre-processor is awkward, fragile, and ugly. It's parsed, processed, and structured differently from the code -- it has different tokens and different semantics; it can lead to code that's a nightmare to maintain, and makes automatic source processing much harder.
And the Java-specific answer is that, as the parent says about 'goto', there are better ways to do any of the things you might want a preprocessor for:
- Probably the main one is to work around different compilers, OSs, architectures, and platforms. But Java is one platform; if you need to do something that different on each underlying OS or system, then you're doing something wrong!
-
Another reason is isolation of constants and other singletons (is that what you mean by your comment about 'login'?); but Java has better ways to handle these (class constants, static finals, singletons, &c).
-
A third reason is optimisation; but that's the sort of thing that a dynamic compiler can probably decide better than you can, especially given that your code may run on different JVMs with different characteristics. (Some 'optimisations' made to early Java code actually slow it down when run on more recent dynamic JVMs.)
-
A fourth is conditional compilation for assertions or other development aids; again, you can do this more neatly with a simple 'if' statement -- and a decent compiler or runtime will optimise it away when not used.
In short, there are no reasons for a preprocessor in Java, and lots of reasons against.Seriously, no one's claiming that the GIMP is no good to anyone. Nor that it's not a decent achievement, nor that it might not be the best value-for-money for many folks.
But if open source software is to live up to some of the hype that its own community generates, then it should also stand some comparison on merit, regardless of cost.
In some cases, it does -- LilyPond, for example, delivers the best-quality music engraving I've seen on any consumer package, better than what I've seen of Sibelius, and certainly better than my copy of Cubase (which excels at other things, of course). And of course, we all know how well it does at OS-level and similar software. In other cases, it's near enough for many people.
But if we're going to take the attitude that "It's free, so it doesn't need to be much good", then we're falling far, far short of our potential.
That's certainly one explanation for why many experienced Photoshop users don't like the GIMP when they see it.
But it doesn't explain why some experienced GIMP users prefer Photoshop when they see that -- as reported in other comments. Nor why some users dislike the GIMP without having seen Photoshop. So that's not the only factor; maybe not the major one.
Half of UI design is simply forgetting what you know about computers in general, and your bit of software in particular. You'd think it'd be easier to forget than to learn! You just have to step back and ask questions like: what's the user trying to do here? What mindset will they start off with? What will they expect? How can we make it easy for them? How little do they need to learn to do it?
Yes, sometimes coming up with the right UI will involve lots of UI experience, having learned techniques and tools, or having that mindset. But I reckon half the time it's simply down to caring about the UI, stopping for a moment and asking whether this whizzy bit of code you're keen on is really the best thing for the user, or whether something simpler or less clever will be better.
The other thing you need is discipline. Sometimes providing two different ways to do something is worse than just providing one, especially if neither do it properly. Sometimes you need to keep things simple and uncluttered -- having to shoe-horn stuff together that doesn't naturally fit is often a sign of deeper problems in your underlying model. Sometimes you need to restrict what your users can do. After all, it's better to do one thing really well than several things badly. And sometimes you need to respect platform/system/community standards, even if you don't like them.
As usual, I've rambled too long. But if all developers cared about their user interfaces, and had the discipline to do what was needed, then all software would benefit.
My dictionary (Concise Oxford) notes that this stressed form of 'to' has been spelled 'too' since the 16th century. Ever felt behind the times?
If you're going to add in extra information from somewhere, surely it's better to keep individual tracks and add in just the exact length; that way, players should be able to tell exactly when to stop playing and move on to the next track seamlessly. Should be a much simpler change, and degrade more gracefully.
Even in that case, though, it shouldn't be too hard for the software to see that the sound stops abruptly half-way through the last frame, and infer the endpoint?
And of course even that partial solution isn't available on the iPod.
Being able to merge tracks together on import is great for a few specific situations, but it's not a general solution either. What if you want to keep the individual track index points? Or the titles, artists, and other information? (Many of my CDs have continuous music, and I don't want to rip each CD as a single track!) What if you've already ripped, or got the tracks from elsewhere?
Why is seamless playback so long in coming? I'd have thought it was a no-brainer. And it can't be that hard to implement, surely.
Oh, absolutely. But I don't think this works the way around you expect. I don't want to have to choose which quarter of my music collection to put on my iPod!
Insisting on more than one of those simply makes passwords impossible to remember, so of course people will write them down &c -- making them less secure, not more.
(I get round that by storing them on my Psion. In a password-protected file! Though with my Psion permanently within reach, that's not so much of an issue.)
Problem: Too many incompatible languages.
Solution: Another incompatible language!
Hmmm... I wonder what's wrong with this picture...
That's what people know, so that's what people use, for better or worse. People don't know that there are alternatives; they don't want to change from one email app to another; they don't know people who'd help them; they don't know if there are apps on other platforms for doing what they currently do; they don't know if all their hardware will be supported; they don't know if and they worry greatly about file compatibility.
Some of these concerns are justified; some are not. But the biggest concern underlying these is fear of change. To get people to switch, you have to provide benefits outweighing that fear. These benefits may be killer apps, greater security, greater ease of use, lower cost, inertia (if something else is pre-installed on a new machine)... currently Linux has some of these, but falls down on others. Mac OS X falls down on different ones. But nothing completely outweighs that fear at the moment. And while fear of change is there, Windows will continue to be popular for no better reason than that it's popular.
I think this is one of the biggest problems with open source software usability. Part of what makes Mac OS X and Windows so easy to use is their consistency -- things generally work the way you expect them to. Yes, it's true that individual applications occasionally have special requirements that mandate something else, but this is far rarer than many developers think. It's easy to think, whether consciously or not, "This app is far too important (or I'm too important/intelligent/creative) to be bound by these boring conventions", when a bit more thought could find a solution which is consistent and good for your app. The result is that every app goes its own way to some extent, and that the entire platform loses out as a result.
I propose the following rules for breaking a common UI convention:
Of course, this rather assumes you can determine what the convention is to begin with -- not always easy with open source...
And what about albums like The War Of The Worlds, where there's continuous music throughout? Actually, quite a good number of my CDs are like this, and dropping in and out is extremely jarring. There's a similar problem with live albums.
And at the other end of the scale are many of my classical CDs (again, a good number) -- a single short movement of a work just isn't enough.
And what about compilations and mix CDs which have a number of songs sequenced with cross-fades?
Not to mention the fact that with as many varied styles and genres as I have, jumping straight from metal to spoken word to folk to funk to soundtrack to synth pop to instrumental can be extremely jarring.
IMO, if shuffle by track works for you, then you either have a very limited collection, or no taste!
Doesn't Mac OS X count? Or EPOC? In fact, just about every non-Windows OS I've used...
That's a real pity. I think most children tend to like learning generally -- that's what they're wired up to do. If they don't want to learn these things, then that's because they're being taught badly, or motivated badly, or something else is preventing them. That's the problem.
Hmmm. So the aim of education is:
Well, that's a laudable and valuable aim, certainly, but there others I can think of:
- To teach general problem-solving and research skills, so that when people come across problems they've not learned to solve directly, as they will, they can work out or find out the solution.
- To teach skills that are likely to be of direct use in employment. (Though this one is less important than many employers seem to think...)
- To get children thinking about the world around them.
- To bring awareness and appreciation of subjects and areas of knowledge that they've not been exposed to, so that they can explore them further if they wish. For example, many children may not otherwise get any real exposure to classical music -- some won't enjoy it much, of course, but some will, and that pleasure can last the rest of their life. The same applies to many other subjects. How can you get interested in science, say, or history, or the classics, if you never hear any of it?
I'm not decrying the teaching of basic maths and English -- they are probably the most important skills, and over the last generation have often been taught extremely badly. Standards of both are lamentable in far too many people.But shouldn't education aim even higher still? Shouldn't it try to balance all of these aims to some extent?
You don't need to be given that right; you have it already. The general situation is this:
So nothing's stopping you from using GPLed software, even if you don't accept the GPL. However, you must accept the GPL in order to distribute it, because otherwise you wouldn't have that right.Yes, that's true and a valid PoV.
But we're talking about software quality here. Doesn't open source software compare well to closed-source on merit? Or do we need to excuse its technical shortcomings on the grounds of its philosophy?
Oh yes, very true. More people should realise this. But I think many people could be a bit better at it than they are, if they put a little thought into it. Ego is one problem -- as the parent says, programmers often code for bragging rights, so they want their work to be seen. But a good UI is often not seen; it gets out of the way so that people can actually use the software. If programmers tried a little harder to think of their users, and what the users are trying to do, then I think things would improve.
(And I can't resist a little rant here about skins. IMO, a good UI should be elegant and simple, and not need skins. As such, skins are a tacit admission of bad UI design.)
I'm fairly lucky in that most of the OS software I've written has had me as a user. That gives valuable insight into what the software is there to do, and keeps me focused on the right things. It also lets me use trial and error over reasonable periods of time to see what works, as well as getting feedback from users.
The main lesson is that simplicity, elegance, and consistency are vital. Not just at the level of widgets or whatever, but (even more so) in the mental models and ideas behind it all. If you get the right abstractions at the heart of the software, then the UI and everything else are much, much easier to get right.
But yes, as everyone else has said, Iomega seem to be living in a dreamworld. Back when floppy was outdated and everyone expected a 'son of floppy' to become 'the standard', they had a chance; but now, people are so used to using CD-Rs and DVD-Rs for backups, and flash and USB drives for transferring files, this seems to be a pointless exercise.
In particular, this new one includes the drive motor and heads in the cartridge. So what's in the drive unit? And how are these cartridges any different from bog-standard IDE HDs? Other than the size. And that HDs are known to be reliable, steadily decreasing in price and increasing in capacity, portable between machines, and a standard...