But B (success) is already true, so, yes, he's correct in stating that learning X makes no difference. F -> T, and T -> T are both true, so the state of A is irrelevant. However, by stating that success is already true, all he's done is stated a fact of logic and not provided a contradiction to the original statement. The only scenario that contradicts the original statement is A -> not B.
Congratulations, you have discovered a well known property of logic. B->A (success implies knowing X) does not necessarily follow from A->B (knowing X implies success). If you were actually trying to prove him wrong, you'd have to find someone who knows X and was not successful.
Right, well, quick-sort hits the worst case when your data is sorted/almost sorted, and is only n log(n) for random data. So, if you're assuming that your data isn't random, then it's even more important to not advertise it as n log(n).
Yes, O is an upper-bound, so stating that quicksort has an O(n^3) is technically correct. However, the least-upper bound is most informative, and this is in fact the worst case scenario, O(n^2). Saying O(n log(n)) is incorrect. Saying it has an O(n log(n)) expected time isn't much better, but in some situations, it's easier to think that way.
Honestly, I think the reason it's commonly used that way is because it's introduced in intro data structures courses, where most algorithms have a similar Big-O and expected running time. Quicksort tends to be one of few interesting exceptions, and rather than spend the time explaining the distinction between expected time and Big-O, teachers invent "average Big-O".
Even so, both pieces of information are needed to be useful. If you give me a quicksort and you tell me that it has O(n log(n)), and I find that I'm running into cases where it's running at n^2, it could really be problematic if I was depending on n log(n) running time. However, if you just say it's O(n^2), I might consider it slower than it really is. So, it's important to be clear that it's O(n^2) with an expected polynomial time of n log(n).
Well, consider the source. It was written by a 21 y/o student who has listed his primary language as Visual Basic. Obviously he isn't trained in theory. That said, a nice discovery for him, but not Slashdot news, and definitely not academic journal material.
Quicksort may have a best expected sorting time, but still has an O(n^2), since O is worst case. I think the STL takes a pass at the list to determine how sorted the list appears to be and then picks a sorting algorithm based on that... but it's been awhile since I looked at it.
An addition to that - these people who sue are directly responsible for worse customer support. When customers act irate or agitated now, companies have to cover their ass, pull their techies out of these forums, and clear everything through PR and legal. So, instead of getting a quick turn around answer, you have to wait until the answer gets channeled through half a dozen people. And chances are, since they're covering their ass, they won't give you any useful information.
Just because some academics came up with a "standard" doesn't mean there's a law that says that everyone needs to follow it.
Two comments about that statement. First, w3c standards weren't just made up by academics. If you take a look at the member list, all of the major players are there - IBM, Microsoft, Sun, Intel, Mozilla, etc. There's a long process of debate and editing that goes into those standards.
Second, though true that there isn't a law that everyone needs to follow, there are laws that apply in some countries. How widely it applies depends on the country, but many laws either directly or indirectly reference WCAG guidelines - one of which states:
"Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."
Well, I can't answer some of that, but some notes:
The link provided by Slashdot no longer shows gmail contact list information - I assume Google already changed some of this, and hopefully the new method is more secure.
The top of the file had an AuthToken, and it's unclear to me how much additional information you could have gotten at using that, but the file itself only contained contact information, not message bodies.
An example entry had the following fields: Id, Name, Email, Affinity, Groups, Addressess, Phoness, Imss (yes, Google had extra s's). So, how much could be stolen depends on how much information you kept in the contact information. It could just be an e-mail, or could have also been an address, phone number, and IM information.
I would have pasted example snippets here, but Slashdot didn't like the brackets and other code-like characters.
Really, it seems like there are three different things you would worry about here. 1) Spammers can get people's e-mails. With the amount of spam already out there, I don't think I'd even notice if another spammer got my e-mail address. 2) People can tie your name to your address and phone number. There are so many ways that this information slips through the cracks already - mostly phonebooks - that the determined person could probably figure it out. 3) People can figure out who you communicate with and trust.
This third one seems like the bigger scare to me, and could be used for all sorts of social engineering attacks. Spam filters will accept e-mail from people on your contact list. People are more likely to open an attachment from someone on their contact list. People on your contact list are more likely to care about you, and you open your aunt Betty to various sorts of fraud regarding you.
Works fine in IE6. TFA states "I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three." so I'm not sure where the poster got the idea that it was Firefox only.
IBM shipped phone functionality with the Aptiva's back in the '96 time frame - using the mwave. You could set it up as a phone mail system and stuff too. I don't think the remote use stuff was there though.
I've read a number of posts here arguing that jumping ship to third parties is going to solve the problem, but the reality of politics in the US is that there can only be two parties. The rules dictate how the game is played, and in the US, we have a winner take all system. The existence of three parties in this system reduces the power of the two groups with the most similar ideologies, allowing the minority opinion to gain control. Because of this, it's no surprise that the only independent candidate in the House is from a small state - Vermont, and he works with the democrats.
If people really want more options, they should fight to do away with the winner take all system first. There's a reason why European governments have a lot more parties in the mix - they divide seats up by percentage of the popular vote. With that sort of system, given the current number of seats in the House, you would only have to rally about 700,000 people in the US (.23%) to your cause to get a chance to participate in Congress.
But, you can't do that without a lot of thought either... because there's the potential for giving party leaders way too much power in that system. Anyway, my two cents.
That would be because most governments internationally recognize WCAG as their standard for accessibility, and many laws have been drafted using WCAG as a starting point. The US government is bound by Section 508, and many state governments have something similar. What this lawsuit was about was getting private entities to realize that the ADA does not just apply to their physical locations, but also to the services they provide such as websites. My understanding is that Target was given many opportunities to settle by simply fixing their site, but refused to.
Most of this lawsuit is simply because they don't use the img alt attribute the way it was specified to be used, and making a website usable without a mouse. It's not hard to make a website accessible, and how to do so is well documented. For example, from IBM.
And for a little more info, from one of the witnesses in the case - see the NFB vs. Target heading.
First off, if you are a university professor, stop treating adults like children. You are not a grade school teacher. Your students are paying good money to attend your class, and though some have misplaced priorities, all are there to learn. If they fail, that is their own lesson to learn. Also, students have many perfectly good reasons for missing class - conferences, work schedules, presentations, etc. Professors should be encouraging their students to learn outside of the classroom, not preventing them from doing so.
As far as podcasts go, while I was in grad school, I took an intro biochem course where they recorded all of the lectures and podcasted it. Absolutely loved it. I had to miss two clases for a conference, and another because I was ill, and didn't have to miss any material. It was also an excellent way to review for a comprehensive final. Also, the course was taught by four profs, one of which had a heavy accent, so it was nice to be able to go back and catch all of the things I had missed the first time around.
There are some high range displays (at least in research facilities) giving you a larger dynamic per color than the 256 scales of traditional 24 bit images, so the lack of "true colors" mentioned in the article might be solved by conventional technology.
You're right that primary colors aren't a phenomenon of physics, but rather of physiology. We can fake the human sensor into seeing the other wavelengths by independently stimulating the red, green, and blue sensors, each of which has a frequency response range. We could reproduce all colors if we can independently stimulate each sensor. Unfortunately, the frequency responses overlap, so we can't really indepedently stimulate each sensor. Here's a nice experiment that shows the problem. In order to reproduce all colors with only three light generators, we need to produce negative light... which doesn't make any sense. So, we pick three colors that do good enough and approximate it.
The problem that tends to be addressed by research displays is that of dynamic range - how bright the colors are, not how true they are. Traditional monitors have a very small brightness range - some are poor with dark stuff, and all are awful for bright scenes. So, outdoor scenes require a very bright monitor to reproduce. The research displays can produce much brighter colors - in fact one claimed you might need to wear sunglasses if cranked up. As you might imagine, there are a lot of problems with heat and all that.
The one part of the spectrum that these high dynamic range displays can be better at is reproducing violet. Since red and green overlap blue a little, to reproduce a good violet, you need to shift the blue pixel toward violet. However, if you do this, since we have a low response to violet, you need a very bright violet to still be able to produce blue, which isn't practical for normal displays.
I agree that there's no technical reason to - and most platforms support including shortcuts as separate resource files, but just because it can be done doesn't mean it is. For one, changing the shortcuts for all of the languages would require additional test since it can introduce key conflicts that aren't on the primary build. Straight translation doesn't have as much of an impact, so apps will just leave it as is to avoid the extra test cost.
In addition, for the products I've worked on, translation has always been the last step in the process, and is done by translators outside the dev team. Translators aren't about to change the shortcuts in case they introduce a conflict, so then it has to swing back to the devs to pick appropriate shortcuts - more dev cost. And the problem is complicated further by languages like Japanese, where the devs may not even have a keyboard capable of easily creating the keys. So, widget sets just put the mneumonic in parens after the menu item.
So, my point in all that was that it's not a technical limitation - it's a limitation of process and practicality.
Honestly, I think the reason things like the multi-touch display is that we're too focused on having a single device for everything - or rather the price point isn't low enough yet not to. A vast majority of what people do on their computers is generate text... word processing, e-mailing, IMing, etc. That multi-touch display is no replacement for a physical keyboard. Yeah, you can pop one up on screen, but how many people have you heard complain about a keyboard just not feeling right? While such a display might be nice for art, photos, mapping, etc, it would be awful for what most people do most of the time, and businesses aren't going to sink money into that.
Another downside to such a display is that it would be physically stressful for prolonged use. There's a reason we train ourselves to touch type and use keyboard navigation. I'm not too thrilled by the idea of my primary interface being one that requires large arm movements.
Despite all that, the other reason UIs don't change much is that what people seem to see as UI advances just complicate the UI rather than simplify it. I love how the AI word spends all of their time trying to reduce dimensionality, and the UI world is always trying to increase it. Keep it simple! A cooler looking, higher dimensional UI is not necessarily a better UI.
#2: I think his complaint is that standard practice tends to be that mneumonics are chosen for English, and are kept across translations. So, if you've ever used a platform in another language, often you can still use the computer without knowing that language because all of the shortcuts are still the same. As an English user, that's great... but they're no longer mneumonics for non-English speakers. The reason this is done is that it's typically desired to have mneumonics be unique for a given menu, so they would have to be chosen post-translation, and typical ship processes don't allow for that.
#3: While I agree that standards are good.. the reason the industry doesn't standardize is that there is no perfect widget set. There are tradeoffs, and the lack of standardization is just the manifestation of these tradeoffs. However, I think they take it a big too far... HTML doesn't exactly have a large widget set, but look at all the things you can do with it.
#4: You notice the reason for this alot more when working with blind users. People can't stand any delay between the key being pressed and the information reaching them. For the blind, a seemingly unnoticeable delay between keypress and speech response will bother them. For me, it's the animation that brings up the menu before the menu is usable (I always turn that junk off). While animations are nice for the inexperienced user to help them train their attention to focus on a given screen area for a particular key press, once our attention focus has been trained, we get impatient with such things.
I'd be careful about that - That website was for the December 2005 recall. Since the Dell recall list doesn't list the current round of recalls, this website may not be up to date. In other words, if your battery shows up as clear on this site today... I'd take another look around in a week or so.
Blind users don't use the mouse. AT ALL. Evidence that you just don't get it.
Blind users have to navigate using the keyboard, and navigation is done by structure. This structure can be the number of focusable controls, number of headings, number of items, etc. So, yes.. they do in a manner of speaking memorize the number of tab presses between the controls they want. Some of this is alleviated by shortcut keys (Alt+f, Ctrl+o, etc). However, for tasks like moving the reading point to the main browser window, there is no "Jump to rendering window" key. Any change to the chrome means that they have to retrain themselves for the keys they need to press to perform these types of tasks. Simply having an extra search input control on my toolbar confused my coworker briefly.
Basically, you would run into this for any keyboard user - it's just that blind people are unique in that they're forced to be keyboard only. This is the reason that shortcut keys and menu layouts try to be consistent across applications - because you develop a sort of muscle memory for key sequences for common tasks.
In any case, they'll certainly be able to use IE7, it's just going to cause them to be a little less productive for a short amount of time, and not something that's kind to do to someone as an automatic update. IMHO, auto updates should not be used for apps where significant GUI changes are being made - such as adding tabbed browsing.
Another nasty issue is that any program that has been built and tested with IE 6's web browser control may suddenly stop working if they changed any of the implementations under the MSHTML API, which they've managed to do with past IE upgrades - especially in the page load event mechanisms. Their automatic update to IE may break other programs. Might not, but.. I would categorize it as a high risk component upgrade.
It's also an issue for blind users. Oh, by the way, we automatically changed your browser interface. I hope you didn't have anything important to do this week because you're going to have to re-memorize a new interface now.
I was a TA a couple of years ago for the intro java course at a Big 10 university, and I'd recommend using Eclipse - at least for the Java part. Honestly, you can show them the non-IDE approach in a day, and cover your bases. The only thing of value you're teaching them there is that javac makes byte code, and how to run the virtual machine/set up a class path. For students with a year under their belt, it shouldn't take them too long to figure this out.
We used to use a poor IDE, but a number of the grad students convinced the university to switch to Eclipse. There are a lot of benefits, but here's two:
First, code completion, and tool-tip documentation helps the students learn the API. Students with C++ experience will be trying to overcome the fact that everything's a reference, default virtual methods, garbage collection, and basic java syntax. Forcing them to memorize the API and its associated documentation is a waste of time when good tools exist to feed them this information as they need it. It also does some import statements for you, which is so very nice.
Second, error detection and suggestions teach the students as they go. If they type up a bunch of code and compile it, they'll get some error on the first thing they worked on, and their head will be on something else, so it just confuses them. Eclipse highlights syntax errors as you type, so you catch and correct these errors while your thought process is still in the right context. In addition, Eclipse will suggest corrections for common errors, typos, etc. Error messages may seem intuitive to the experienced programmer, but to a novice, it's just greek. I think I spent most of my lab time trying to convey to students what the error messages really meant, and how they could use them to fix their code.
Bottom line is, learning is a process where you learn one thing at a time, and feedback at any step of the process is good. By using a good IDE, you are able to focus on more general concepts, which are transferable to other languages. Otherwise, they just learn the API and what the error messages mean, and lose a lot of valuable time.
Men buy sport's cars, women inflate their boobs, and graphics researchers get bigger screens. Sure, there's been research that says tiny ass screens make people less productive, but I haven't seen anything that says that a huge ass VR wall will advance research in any way shape or form. It's one of the major short comings of graphics research.. sometimes we get so wrapped up in the wow-factor, that the user studies are never done to figure out if the images that are displayed are actually useful. Too many times, the user studies are whether or not X person preferred it, as opposed to X person was able to be more productive, discover more, etc. One of the first things you learn when working with scientists is that the visualizations that they prefer sometimes lead them to false conclusions.
Side note though.. considering that your effective high resolution field of view is maybe three degrees, they'd be better off spending that money to do research to build an eye tracker connected to a very high resolution single projector, and just project a large, low resolution image for the rest of the wall.. two projectors, and the user wouldn't be the wiser.
Actually, the fact that they do in fact handle repeating events well is exactly the reason I'll be using this calendar. You need to play around a bit more before claiming it doesn't support it, because it does (repeat weekly, just like you would with Sunbird).
Most of the free calendars I've tried are awful for repeating events. For instance, 30 boxes support is recent and minimal. Mozilla Sunbird repeating exception handing is clunky. For instance, if you have a MWF class, and you want to change the description for a particular day to say "EXAM", Google's smart enough to ask you if you want to just change that one instance, or change all of the repeating events. For Sunbird, you'd have to edit the event, create an exception to remove the event that day, and the create a new event. And be careful with Sunbird not to hit delete, or you lose the whole batch. Google at least asks you what you want to do.
Personally, Google's behavior for repeating events reminds me a lot of the old Lotus Organizer, and I've been looking for similar support in something I can host online for a long time.
The only problem I've run into with the Google Cal so far is there seems to be a good amount of lag in reading things from the server, and the cache gets out of synch. So, when I created a new calendar, it didn't show up until I relogged in.. and then after seeing "Loading" for awhile, eventually it did pop up. Hopefully it'll work itself out once the slashdot crowd stops creating millions of new events:P
Depends on how you interpret it. Google started as an academic publication, which is public. The system has certainly grown and changed since then, and improved, and much of that is secret. However, some generalizations of what they do, and particular pieces are patented. I believe this statement is saying that the general system is patented, but many of the scoring details, which is what's relevant in the case, are secret. So... yes, it can be both - you don't have to patent full systems and every detail. And you can also improve upon a patented system and keep those parts secret.
Slashdot Mirror
But B (success) is already true, so, yes, he's correct in stating that learning X makes no difference. F -> T, and T -> T are both true, so the state of A is irrelevant. However, by stating that success is already true, all he's done is stated a fact of logic and not provided a contradiction to the original statement. The only scenario that contradicts the original statement is A -> not B.
Congratulations, you have discovered a well known property of logic. B->A (success implies knowing X) does not necessarily follow from A->B (knowing X implies success). If you were actually trying to prove him wrong, you'd have to find someone who knows X and was not successful.
Right, well, quick-sort hits the worst case when your data is sorted/almost sorted, and is only n log(n) for random data. So, if you're assuming that your data isn't random, then it's even more important to not advertise it as n log(n).
Yes, O is an upper-bound, so stating that quicksort has an O(n^3) is technically correct. However, the least-upper bound is most informative, and this is in fact the worst case scenario, O(n^2). Saying O(n log(n)) is incorrect. Saying it has an O(n log(n)) expected time isn't much better, but in some situations, it's easier to think that way.
Honestly, I think the reason it's commonly used that way is because it's introduced in intro data structures courses, where most algorithms have a similar Big-O and expected running time. Quicksort tends to be one of few interesting exceptions, and rather than spend the time explaining the distinction between expected time and Big-O, teachers invent "average Big-O".
Even so, both pieces of information are needed to be useful. If you give me a quicksort and you tell me that it has O(n log(n)), and I find that I'm running into cases where it's running at n^2, it could really be problematic if I was depending on n log(n) running time. However, if you just say it's O(n^2), I might consider it slower than it really is. So, it's important to be clear that it's O(n^2) with an expected polynomial time of n log(n).
Well, consider the source. It was written by a 21 y/o student who has listed his primary language as Visual Basic. Obviously he isn't trained in theory. That said, a nice discovery for him, but not Slashdot news, and definitely not academic journal material.
Quicksort may have a best expected sorting time, but still has an O(n^2), since O is worst case. I think the STL takes a pass at the list to determine how sorted the list appears to be and then picks a sorting algorithm based on that... but it's been awhile since I looked at it.
An addition to that - these people who sue are directly responsible for worse customer support. When customers act irate or agitated now, companies have to cover their ass, pull their techies out of these forums, and clear everything through PR and legal. So, instead of getting a quick turn around answer, you have to wait until the answer gets channeled through half a dozen people. And chances are, since they're covering their ass, they won't give you any useful information.
Two comments about that statement. First, w3c standards weren't just made up by academics. If you take a look at the member list, all of the major players are there - IBM, Microsoft, Sun, Intel, Mozilla, etc. There's a long process of debate and editing that goes into those standards.
Second, though true that there isn't a law that everyone needs to follow, there are laws that apply in some countries. How widely it applies depends on the country, but many laws either directly or indirectly reference WCAG guidelines - one of which states: "Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported."
Well, I can't answer some of that, but some notes:
- The link provided by Slashdot no longer shows gmail contact list information - I assume Google already changed some of this, and hopefully the new method is more secure.
- The top of the file had an AuthToken, and it's unclear to me how much additional information you could have gotten at using that, but the file itself only contained contact information, not message bodies.
- An example entry had the following fields: Id, Name, Email, Affinity, Groups, Addressess, Phoness, Imss (yes, Google had extra s's). So, how much could be stolen depends on how much information you kept in the contact information. It could just be an e-mail, or could have also been an address, phone number, and IM information.
I would have pasted example snippets here, but Slashdot didn't like the brackets and other code-like characters.Really, it seems like there are three different things you would worry about here. 1) Spammers can get people's e-mails. With the amount of spam already out there, I don't think I'd even notice if another spammer got my e-mail address. 2) People can tie your name to your address and phone number. There are so many ways that this information slips through the cracks already - mostly phonebooks - that the determined person could probably figure it out. 3) People can figure out who you communicate with and trust.
This third one seems like the bigger scare to me, and could be used for all sorts of social engineering attacks. Spam filters will accept e-mail from people on your contact list. People are more likely to open an attachment from someone on their contact list. People on your contact list are more likely to care about you, and you open your aunt Betty to various sorts of fraud regarding you.
Works fine in IE6. TFA states "I've tried the hack on IE7, Opera, and Firefox; it appears to be working on all three." so I'm not sure where the poster got the idea that it was Firefox only.
IBM shipped phone functionality with the Aptiva's back in the '96 time frame - using the mwave. You could set it up as a phone mail system and stuff too. I don't think the remote use stuff was there though.
I've read a number of posts here arguing that jumping ship to third parties is going to solve the problem, but the reality of politics in the US is that there can only be two parties. The rules dictate how the game is played, and in the US, we have a winner take all system. The existence of three parties in this system reduces the power of the two groups with the most similar ideologies, allowing the minority opinion to gain control. Because of this, it's no surprise that the only independent candidate in the House is from a small state - Vermont, and he works with the democrats.
If people really want more options, they should fight to do away with the winner take all system first. There's a reason why European governments have a lot more parties in the mix - they divide seats up by percentage of the popular vote. With that sort of system, given the current number of seats in the House, you would only have to rally about 700,000 people in the US (.23%) to your cause to get a chance to participate in Congress.
But, you can't do that without a lot of thought either... because there's the potential for giving party leaders way too much power in that system. Anyway, my two cents.
That would be because most governments internationally recognize WCAG as their standard for accessibility, and many laws have been drafted using WCAG as a starting point. The US government is bound by Section 508, and many state governments have something similar. What this lawsuit was about was getting private entities to realize that the ADA does not just apply to their physical locations, but also to the services they provide such as websites. My understanding is that Target was given many opportunities to settle by simply fixing their site, but refused to.
Most of this lawsuit is simply because they don't use the img alt attribute the way it was specified to be used, and making a website usable without a mouse. It's not hard to make a website accessible, and how to do so is well documented. For example, from IBM.
And for a little more info, from one of the witnesses in the case - see the NFB vs. Target heading.
First off, if you are a university professor, stop treating adults like children. You are not a grade school teacher. Your students are paying good money to attend your class, and though some have misplaced priorities, all are there to learn. If they fail, that is their own lesson to learn. Also, students have many perfectly good reasons for missing class - conferences, work schedules, presentations, etc. Professors should be encouraging their students to learn outside of the classroom, not preventing them from doing so.
As far as podcasts go, while I was in grad school, I took an intro biochem course where they recorded all of the lectures and podcasted it. Absolutely loved it. I had to miss two clases for a conference, and another because I was ill, and didn't have to miss any material. It was also an excellent way to review for a comprehensive final. Also, the course was taught by four profs, one of which had a heavy accent, so it was nice to be able to go back and catch all of the things I had missed the first time around.
There are some high range displays (at least in research facilities) giving you a larger dynamic per color than the 256 scales of traditional 24 bit images, so the lack of "true colors" mentioned in the article might be solved by conventional technology.
You're right that primary colors aren't a phenomenon of physics, but rather of physiology. We can fake the human sensor into seeing the other wavelengths by independently stimulating the red, green, and blue sensors, each of which has a frequency response range. We could reproduce all colors if we can independently stimulate each sensor. Unfortunately, the frequency responses overlap, so we can't really indepedently stimulate each sensor. Here's a nice experiment that shows the problem. In order to reproduce all colors with only three light generators, we need to produce negative light... which doesn't make any sense. So, we pick three colors that do good enough and approximate it.
The problem that tends to be addressed by research displays is that of dynamic range - how bright the colors are, not how true they are. Traditional monitors have a very small brightness range - some are poor with dark stuff, and all are awful for bright scenes. So, outdoor scenes require a very bright monitor to reproduce. The research displays can produce much brighter colors - in fact one claimed you might need to wear sunglasses if cranked up. As you might imagine, there are a lot of problems with heat and all that.
The one part of the spectrum that these high dynamic range displays can be better at is reproducing violet. Since red and green overlap blue a little, to reproduce a good violet, you need to shift the blue pixel toward violet. However, if you do this, since we have a low response to violet, you need a very bright violet to still be able to produce blue, which isn't practical for normal displays.
I agree that there's no technical reason to - and most platforms support including shortcuts as separate resource files, but just because it can be done doesn't mean it is. For one, changing the shortcuts for all of the languages would require additional test since it can introduce key conflicts that aren't on the primary build. Straight translation doesn't have as much of an impact, so apps will just leave it as is to avoid the extra test cost.
In addition, for the products I've worked on, translation has always been the last step in the process, and is done by translators outside the dev team. Translators aren't about to change the shortcuts in case they introduce a conflict, so then it has to swing back to the devs to pick appropriate shortcuts - more dev cost. And the problem is complicated further by languages like Japanese, where the devs may not even have a keyboard capable of easily creating the keys. So, widget sets just put the mneumonic in parens after the menu item.
So, my point in all that was that it's not a technical limitation - it's a limitation of process and practicality.
Honestly, I think the reason things like the multi-touch display is that we're too focused on having a single device for everything - or rather the price point isn't low enough yet not to. A vast majority of what people do on their computers is generate text... word processing, e-mailing, IMing, etc. That multi-touch display is no replacement for a physical keyboard. Yeah, you can pop one up on screen, but how many people have you heard complain about a keyboard just not feeling right? While such a display might be nice for art, photos, mapping, etc, it would be awful for what most people do most of the time, and businesses aren't going to sink money into that.
Another downside to such a display is that it would be physically stressful for prolonged use. There's a reason we train ourselves to touch type and use keyboard navigation. I'm not too thrilled by the idea of my primary interface being one that requires large arm movements.
Despite all that, the other reason UIs don't change much is that what people seem to see as UI advances just complicate the UI rather than simplify it. I love how the AI word spends all of their time trying to reduce dimensionality, and the UI world is always trying to increase it. Keep it simple! A cooler looking, higher dimensional UI is not necessarily a better UI.
Some comments:
#2: I think his complaint is that standard practice tends to be that mneumonics are chosen for English, and are kept across translations. So, if you've ever used a platform in another language, often you can still use the computer without knowing that language because all of the shortcuts are still the same. As an English user, that's great... but they're no longer mneumonics for non-English speakers. The reason this is done is that it's typically desired to have mneumonics be unique for a given menu, so they would have to be chosen post-translation, and typical ship processes don't allow for that.
#3: While I agree that standards are good.. the reason the industry doesn't standardize is that there is no perfect widget set. There are tradeoffs, and the lack of standardization is just the manifestation of these tradeoffs. However, I think they take it a big too far... HTML doesn't exactly have a large widget set, but look at all the things you can do with it.
#4: You notice the reason for this alot more when working with blind users. People can't stand any delay between the key being pressed and the information reaching them. For the blind, a seemingly unnoticeable delay between keypress and speech response will bother them. For me, it's the animation that brings up the menu before the menu is usable (I always turn that junk off). While animations are nice for the inexperienced user to help them train their attention to focus on a given screen area for a particular key press, once our attention focus has been trained, we get impatient with such things.
I'd be careful about that - That website was for the December 2005 recall. Since the Dell recall list doesn't list the current round of recalls, this website may not be up to date. In other words, if your battery shows up as clear on this site today... I'd take another look around in a week or so.
Blind users don't use the mouse. AT ALL. Evidence that you just don't get it.
Blind users have to navigate using the keyboard, and navigation is done by structure. This structure can be the number of focusable controls, number of headings, number of items, etc. So, yes.. they do in a manner of speaking memorize the number of tab presses between the controls they want. Some of this is alleviated by shortcut keys (Alt+f, Ctrl+o, etc). However, for tasks like moving the reading point to the main browser window, there is no "Jump to rendering window" key. Any change to the chrome means that they have to retrain themselves for the keys they need to press to perform these types of tasks. Simply having an extra search input control on my toolbar confused my coworker briefly.
Basically, you would run into this for any keyboard user - it's just that blind people are unique in that they're forced to be keyboard only. This is the reason that shortcut keys and menu layouts try to be consistent across applications - because you develop a sort of muscle memory for key sequences for common tasks.
In any case, they'll certainly be able to use IE7, it's just going to cause them to be a little less productive for a short amount of time, and not something that's kind to do to someone as an automatic update. IMHO, auto updates should not be used for apps where significant GUI changes are being made - such as adding tabbed browsing.
Another nasty issue is that any program that has been built and tested with IE 6's web browser control may suddenly stop working if they changed any of the implementations under the MSHTML API, which they've managed to do with past IE upgrades - especially in the page load event mechanisms. Their automatic update to IE may break other programs. Might not, but.. I would categorize it as a high risk component upgrade.
It's also an issue for blind users. Oh, by the way, we automatically changed your browser interface. I hope you didn't have anything important to do this week because you're going to have to re-memorize a new interface now.
I was a TA a couple of years ago for the intro java course at a Big 10 university, and I'd recommend using Eclipse - at least for the Java part. Honestly, you can show them the non-IDE approach in a day, and cover your bases. The only thing of value you're teaching them there is that javac makes byte code, and how to run the virtual machine/set up a class path. For students with a year under their belt, it shouldn't take them too long to figure this out.
We used to use a poor IDE, but a number of the grad students convinced the university to switch to Eclipse. There are a lot of benefits, but here's two:
First, code completion, and tool-tip documentation helps the students learn the API. Students with C++ experience will be trying to overcome the fact that everything's a reference, default virtual methods, garbage collection, and basic java syntax. Forcing them to memorize the API and its associated documentation is a waste of time when good tools exist to feed them this information as they need it. It also does some import statements for you, which is so very nice.
Second, error detection and suggestions teach the students as they go. If they type up a bunch of code and compile it, they'll get some error on the first thing they worked on, and their head will be on something else, so it just confuses them. Eclipse highlights syntax errors as you type, so you catch and correct these errors while your thought process is still in the right context. In addition, Eclipse will suggest corrections for common errors, typos, etc. Error messages may seem intuitive to the experienced programmer, but to a novice, it's just greek. I think I spent most of my lab time trying to convey to students what the error messages really meant, and how they could use them to fix their code.
Bottom line is, learning is a process where you learn one thing at a time, and feedback at any step of the process is good. By using a good IDE, you are able to focus on more general concepts, which are transferable to other languages. Otherwise, they just learn the API and what the error messages mean, and lose a lot of valuable time.
Just my two cents.
Men buy sport's cars, women inflate their boobs, and graphics researchers get bigger screens. Sure, there's been research that says tiny ass screens make people less productive, but I haven't seen anything that says that a huge ass VR wall will advance research in any way shape or form. It's one of the major short comings of graphics research.. sometimes we get so wrapped up in the wow-factor, that the user studies are never done to figure out if the images that are displayed are actually useful. Too many times, the user studies are whether or not X person preferred it, as opposed to X person was able to be more productive, discover more, etc. One of the first things you learn when working with scientists is that the visualizations that they prefer sometimes lead them to false conclusions.
Side note though.. considering that your effective high resolution field of view is maybe three degrees, they'd be better off spending that money to do research to build an eye tracker connected to a very high resolution single projector, and just project a large, low resolution image for the rest of the wall.. two projectors, and the user wouldn't be the wiser.
Actually, the fact that they do in fact handle repeating events well is exactly the reason I'll be using this calendar. You need to play around a bit more before claiming it doesn't support it, because it does (repeat weekly, just like you would with Sunbird).
:P
Most of the free calendars I've tried are awful for repeating events. For instance, 30 boxes support is recent and minimal. Mozilla Sunbird repeating exception handing is clunky. For instance, if you have a MWF class, and you want to change the description for a particular day to say "EXAM", Google's smart enough to ask you if you want to just change that one instance, or change all of the repeating events. For Sunbird, you'd have to edit the event, create an exception to remove the event that day, and the create a new event. And be careful with Sunbird not to hit delete, or you lose the whole batch. Google at least asks you what you want to do.
Personally, Google's behavior for repeating events reminds me a lot of the old Lotus Organizer, and I've been looking for similar support in something I can host online for a long time.
The only problem I've run into with the Google Cal so far is there seems to be a good amount of lag in reading things from the server, and the cache gets out of synch. So, when I created a new calendar, it didn't show up until I relogged in.. and then after seeing "Loading" for awhile, eventually it did pop up. Hopefully it'll work itself out once the slashdot crowd stops creating millions of new events
Depends on how you interpret it. Google started as an academic publication, which is public. The system has certainly grown and changed since then, and improved, and much of that is secret. However, some generalizations of what they do, and particular pieces are patented. I believe this statement is saying that the general system is patented, but many of the scoring details, which is what's relevant in the case, are secret. So... yes, it can be both - you don't have to patent full systems and every detail. And you can also improve upon a patented system and keep those parts secret.
Ah.. ok. I just assumed with all of the teens with profiles saying they were in their 20s that the cutoff was 18. Thanks for the correction.