I'll never understand why is so important that an OS will be pre-installed with the machine.
Because there is a big difference between making the claim that a machine is "Linux Compatible" and actually shipping with a tested version pre-installed as a demonstration that there are drivers for all components
Considering how quickly companies tend to SUE you for disclosing a vulnerability, I don't think there can be any true code of conduct between hackers and companies.
So Apple sued the guy who disclosed this Quicktime vulnerability? If that happened, I never heard about it. In fact, I work i the security industry and very, very rarely hear about any lawsuits, which is why they are news when they do happen.
Not unless the companies start making it (public) policy that they WILL NOT sue you as long as you disclose a vulnerability to them first, and give them a reasonable time to fix it before going public.
Why? Would such a statement stop them from later doing it? In general companies don't sue over vulnerability disclosures, no matter whether they are immediate, or if the vendor is given time. The reason security researchers tend to give companies time to fix things is because that is what they think is best for security, overall.
I think that'll never happen though, and the only way to safeguard a hacker is to make legislation against those type of lawsuits.
That doesn't really work. Basically you can sue anyone for anything in the US (with very few exceptions). I don't see the need for one here since I very rarely, if ever, hear about anyone being sued for disclosing bugs.
Responsible disclosure is nothing more than security through obscurity. And security through obscurity is as good as no security at all.
Actually, security through obscurity is very functional and useful as part of a security scheme. Your password is security through obscurity. Why don't you just give it to everyone if it makes no difference?
In the intervening months, you have a live, exploitable hole sitting there ripe for attack!
And if you disclose the wrong vulnerability to the general public you have a live, exploitable hole that everyone knows about sitting there ripe for attack. Which is better?
Responsible disclosure is simply evaluating what is best for the security of users and disclosing i that manner. n some cases, the best thing for overall security is immediate, public disclosure to pressure the vendor into fixing the hole more quickly and to give users a chance to work around the vulnerability. In other cases, where the vendor is responsive, and ther is no easy way to mitigate the vulnerability for the end user, immediate disclosure increases the risk to users with no real benefit.
I say, damn the consequences. Report as soon as possible no matter who it embarrasses.
Who is embarrassed is immaterial. Ignoring the likely consequences of you disclosure method, however, is irresponsible, which is why the alternative is called "responsible disclosure."
It'll either put more pressure on them to fix the bugs faster...
In many cases the vendor is very motivated and goes to work with all their resources immediately. Take a look at the OmniWeb vulnerability published by the MOAB project. Omnigroup implemented a fix within a day and had it available for download, but they do the same thing for bugs disclosed to them privately. All the immediate disclosure did was give hackers more time to exploit the problem before the fix reached users. Disclosing a vulnerability to the public before sending it to a responsible and security minded development team is good for no one but blackhats. Also, rushing vendors to write code faster, can result in more bugs in said code, including other vulnerabilities or or bugs.
...or push users to more secure platforms where security fixes don't take months and are usually found before their ever exploited in the wild.
Please. Most users will not switch platforms because of security issues and many are locked into MS's desktop monopoly by some software they absolutely need and price constraints. The vast majority of users never even hear about security vulnerability disclosure in the first place.
Here's a tip for you from someone who does work in the security industry. If you're looking for a job in the field, don't expose your irresponsible ideas about disclosure if you want a chance at being hired somewhere respectable.
As to whether that law restricts your free speech, the claim is that "hate speech" is not protected by the Constitution, particularly when it interferes with the right of others to worship freely.
All expression is protected by the constitution. The only issue is when one person's right to express themselves comes into conflict with another person's constitutionally protected right. For example, if I tell my crime syndicate goons to go kill you, and I'm caught, I still go to jail for conspiracy to commit murder, even though my only act was expression. That is because my right to free expression was trumped by your right to live.
The question then, is: "does some given 'hate speech' conflict with another right, such as the right to religious freedom?" I'd say it does only when it is likely to interfere with that right, which most hate crime laws use the probability of some violent action, being the determining factor. Is it reasonable to assume people would act violently against Scientologists or Christians or Muslims, because of what I said?
Here's a puzzler for you. Suppose I found a religion with two basic principals. First, we will use our magic powers via meditation to make everyone who is not a member either become a member or die of cancer by the invisible hand of our god. Second, in order to be saved, we must spread the word and tell everyone of our religion.
What happens to the application of CA law to Scientology in that instance. Sure a person is threatening another religion, in fact all other religions... but it is their right under both free speech and freedom of religion to do so and to stop them would be to deny them both those rights for the sake of theoretically protecting a different religion from a threat which is not scientifically credible. How does California's law have any claim to constitutionality in such a circumstance?
Before I get into this rebuttal, I would like to point out that I believe your confusion originated because you learned computing on a Macintosh.
Umm, I did not learn computing on a Macinstosh. I Learned on a Commadore64, then an Apple2C, then a variety of computers in school. In fact, the first computer I ever owned personally was a hybrid machine containing both a 66Mhz PPC chip and a 66Mhz 486, which had a built in KVM. I think this actually makes me one of the very few people to have started off with no mac or PC bias as I spent a lot of time instantly able to switch between the two OS's. The input devices I used were the keyboard and a four button track ball (the olde fashoined kind, like from centipede).
The precise procedure is as follows:
That does not work in my version of OpenOffice. You have to highlight the word first. As I mentioned, I don't have a Hotmail account for testing, but you seem to have missed the point. The difficulty that arises is not in the step where one must highlight the word, but where one must either hold down the button while scrolling down the list, or, use both the right and left buttons for the same procedure.
You're right, but you have set up the dichotomy wrong. The comparison really should be between new users and the so-called computer literate. You do not even need to be close to expert for the context menu to be faster, in this case.
It is not a dichotomy. What a given person considers an "expert" is very relative. Since this software (hotmail) is targeting the general populace, I'll ask you a question, "have you ever watched a usability study where the users were the general public?" If you have, you would probably not consider the use of and learning of the right mouse button to be a non-issue. It is the single, number one, most common usability issue in every computer usability study with the general public I've personally seen, and in almost every one I've read.
Let's run your example:
I actually did not give an example, but I did mention use of a button. The point I was bringing up is that for the general user, there are methods that are as fast if not faster, when actually used, rather than in the theoretical use cases you show. For example, you fail to account for people selecting the wrong word, or hitting the wrong mouse button when trying to use your context menu, which is a common case and which slows overall usage. You did not account for users who will click both buttons simultaneously all the rime, but who tend to unconsciously hit the left button more commonly. You did not account for users who will not find this function at all and who will go get a dictionary and correct by hand.
I mentioned a button because it usually results in static behavior. You don't have a menu that will go away if you accidentally click. There is also the use case of a spelling checker that is run on command and which asks the user about each misspelled word. In some cases, this is actually faster.
My point is, context menus are for expert users in front of a Windows box. If you're targeting the general public (like hotmail) it should not be the primary interface for a function and it should certainly not be the only interface.
Granted, but I don't care. I know that you started by replying in regards to hotmail. I, on the other hand, am not here to extol the virtues (or berate the faults) of hotmail. I'm here because you made a very broad incorrect declaration: "Right-clciking and selecting a menu option is a lot slower and less learnable than a button".
I made that in the context of a discussion about hotmail and with regard to a class of users. Right-clicking is almost always going to be less learnable in the general case than a button, except for very particular user groups. As for speed, that depends entirely upon the use case and there was one under discussion.
I wouldn't suggest that context menus be the only way to access a function, but they are the best.
The whole point of this discussion was that they should not be the only way to access the function, as they are in this new version of Hotmail. They are fine as a secondary mechanism.
Well I was talking buttons.
That was your incorrect assumption.
As for menus, you first have to select which menu you need from the horizontal list of menus (file, edit, view, etc) then you go down a vertical menu. With context menus you right click and the menu you want is right there, no searching in 2 dimensions.
Okay, since you seem to have never looked into the topic, here are the general usability rules for menus and the reasons for them. If you have 7 or fewer controls, use buttons. If you have fewer than 64 controls, use menus, with no more than 8 top level menus. If you have more than 15 items in a menu, you'll have problems. If you have nested menus, you'll have problems.
Now right-click menus are special because of the usability concerns they bring up. They should never, ever be the only way to access something, so they are always duplicating something you have elsewhere. They can be duplicating items in a nested menu, if you don't have a better option. They should always be customizable, since they are repeats, not primary access controls, and the user always knows their workflow better than the designer. If at any point you have more than about 12 items in your context menu, you will have serious problems with usability.
As for learnability, sometimes it's better to sacrifice learnability for power.
I agree. I disagree that this is one of those cases. This is a Webmail service. It targets a wide range of complete novices and the general public including people with disabilities, or who are using cell phones, and many other cases that cannot be accounted for.
It only takes 5 seconds to explain to someone what the right click button is for, and they keep that with them for the rest of their lives.
Spoken like someone who has never watched a usability test. Average users forget functions they do not use all the time. A lot of users check their e-mail once every few weeks. Just telling them where the right-click button is and what it is for is not enough and who exactly will be telling users of hotmail this?
They'll save much more time using the context menu than they spent learning how to use it.
No, they simply won't learn how to use it and will not use any function only there. For a reasonable subset of users (novices, disabled, phone users, tablet users, voice recog users, some alternate browser users, etc. it will be as though that function is not even there... and that is a big design failure.
What bibliography formatting service are you talking about?
Hmm, good question. It is an OS X system service called "BibliographyService." It may have come with BibDesk, but it does not seem to be grouped with the other services from there. It may be a stand alone service I grabbed somewhere.
A "web application" isn't if it does not require remote for processing and storing. It is just a local application run in a browser.
True, but that's not what we're talking about. We're talking about applications that run via a Web browser and integrate with a Web service (Google Docs), but which also run locally without Web access, albeit with some features disabled. It is important to note, we were speaking about the desktop metaphor being dead, and when your app is running locally in a browser, that does seem to be the case to a significant extent.
For example, gmail has a nice view run locally in the browser.
I'm afraid I have no idea what you were trying to say with that sentence. Could you please be a little clearer.
You cannot send or receive email if you are not online.
So? The point is to allow you to compose messages in Gmail when offline. More importantly, for applications whose primary purpose is not communication via the Web (games, photo editor, word processor, spreadsheets, calculators, etc.) it will allow them to be functional offline, only adding functionality when online.
Desktop is NOT dead.
The desktop is not dead. The desktop is threatened as a control metaphor, by the browser. I, personally, don't think Redhat's plan is sound or their vision is accurate. I never argued that they did. I merely pointed out the problems with the assertions that Web applications are not useful because they don't function when offline. Since they are moving towards a more hybrid approach, that is a dated view.
I also understand where Redhat is coming from. The desktop OS has stagnated. Most users still do not have (and will not for the foreseeable future) have spellchecking available in all applications. That is just sad. Any possible way to undermine MS's monopoly and add functionality despite their stubborn refusal to move forward gets developers excited. Anything that removes user's dependancy on Windows is a plus for me.
Often I use my laptop in the subway. Guess what? No internet access. So how would I perform my work with such a paradigm?
The mozilla team has already talked about Firefox 3's upcoming support for running online apps while offline, as a sort of hybrid, but still within the browser. Just do a search for "web applications offline' and you'll find dozens of articles including how-to sites from tool providers for making Web apps that will function offline right now.
To user the desktop metaphor is not dead when offline.
I'm not sold on Web applications. I'm not sold on a strategy of bypassing MS by building everything on top of them. I'd rather see cross platform applications with internet capabilities, or hybrid solutions, that still allow me to take advantage of the benefits of the OS. From a practical standpoint, however, my automatic bibliography formatting service allows me to automatically format bibliography references right now using Google Docs, but I can't use the same functionality in Wordpad or in MSWord for that matter; so in some ways online apps are already allowing me to bypass the limitations of Microsoft's OS.
That is absolutly NOT true. Compare classicly styled spell checkers with the ones offered by current versions of Word and Open Office. You right click on a specific word and are instantly given a list of available spellings.
Actually, the procedure for using it is: highlight the word (usually by double clicking), then right click, then select correct spelling from the provided list, then release the button. In general, the workflow of highlighting a word, then hitting a button and navigating a dialogue in a standard location is faster for new users and slower for expert users, in that instance, but you're failing to account for the fact that it is a special case where there are very, very few options in the contextual menu. As the number of items in the contextual menu gets larger, the operation becomes slower and slower, while the traditional button option remains the same speed. Now this is partially mitigated on a WebUI because the buttons are not always in a persistent location.
As to "learnability" contextual menus are a nonstandard interface item compared to buttons, and one that has no persistent clue. If you don't know you can right click on something, looking at the screen provides you with no clue to that, whereas just looking at the screen a user can see a button for the same function, and may, thus, experiment or investigate and learn what that button does, thus learning to use the feature.
Besides, when someone starts learning to use a computer on a Windows box, they will start right clicking on everything to learn their options.
For some advanced groups of users this is true, but it is not even close to true for average users in usability tests. The number one usability issue encountered with average users is they don't understand right and left clicking. Some will ask for every button/clickable every time. Some choose randomly. Some always click both buttons simultaneously with somewhat random results. In general, novice users do not ever find and intentionally avoid features in right-click contextual menus. For those reasons such a usage is very inappropriate for a Web mail client that is going to be rolled out to the general public including very novice users.
Context menus allow you to pare down the available functions to what's appropriate.
Context menus are great as a secondary way to access common functions. They are terrible as a primary way for the reasons I listed.
Buttons are always there, so there's going to be a lot more of them, most of which are irrelevant.
Buttons are fine and menus are fine (conceptually, implementations can be poor). Users understand that they exist and can look through them for the function they want.
They could also be anywhere on your screen, a context menu is linear.
Umm, linear? How is a context menu more linear than say a drop down menu? More importantly, how is it more usable?
So it's going to be a lot easier and faster to find the option on the context menu than pretty much anywhere else.
Well it certainly isn't going to be faster to find for a person using a screen reader, since they will never see it. As for everyone else, as I said I'm not opposed to context menus, simply to functions available only by the context menu. A well implemented context menu duplicates certain very common functions and is customizable so the user (who is the only one who knows his own workflow) can further streamline it. They are terrible, however, when used as the primary interface because they remove all flexibility from the interface excluding all the people in situations like those I listed. They also suffer from poor learn-ability and are confusing to novices.
As for less learnable, how do you even quantify that?
Generally via usability testing with software that tracks what a user does with an interface and how long it takes them both to accomplish tasks the first time and then subsequent times. For context menus as exclusive interfaces, however, testing has shown over and over and over again that they are a terrible idea. Alternate interfaces can't use them at all. Novice users often never find those functions or accidentally trigger them. One of the single biggest usability problems with computers today is users that don't know if they should right-click or left-click or don't even distinguish and always click both at once resulting in random results. It is not like this is news. This was exposed as a huge problem in almost all use cases decades ago and has been a standard feature of usability texts and UI design instruction for nearly as long. It is on the "top 10 UI design blunders" list.
If you're programming an interface to a professional CAD application, well your users will figure it out and very few users will need alternative input devices (except those using a stylus and board). If, however, you're programming a Web mail client that will be targeting brand new users it is a disaster. Imagine if you were a disabled person and went to the Web page of the biggest software maker in the US, only to find that their Web mail did not work for you for common tasks, unless you found some hidden setting that would switch it back to their old, deprecated interface? You really think that is okay or good design, when the work around is so easy?
I'm sorry but I've worked in UI design and usability testing, though not for several years. I keep up on the literature. Putting a function only in a right-click menu is a mistake for the clueless novice, not for professionals.
The list updated with misc additions for others who replied:
Gmail - disk space of 2.8+G versus 2G
Hotmail - attachment size, Hotmail claims to allow 10M attachments as the maximum, whereas Gmail claims 10M for the attachment and message combined. (Can anyone confirm the marketing is true?)
Gmail - Free POP support
Tie - I know Gmail has no graphic ads and some text ads and someone is claiming Hotmail has removed graphic ads now too for the free accounts. Can anyone confirm this or provide feedback on the number of ads and the manner they are shown?
Gmail - Spam, last I heard Gmail was winning the spam battle without the high false positive rate that has been plaguing Hotmail. No undeletable spam messages from the service provider
? - interface. Any interface designers with a clue taken a look at both of these?
Gmail - prestige. We interviewed a person with a Gmail address the other day and someone commented that she probably has a clue in technology. At an old job someone made the opposite comment with regard to an applicant with a Hotmail address.
Gmail - cross platform support. The e-mail functions of Gmail works the same way with Safari and Opera, while Hotmail degrades to the old interface in them. Gmail's supported browser list is much more extensive.
Gmail - language support. Gmail claims to support 41 unique languages (not variants) versus Hotmail's 31.
Gmail? - address book import/export - Gmail supports CSV import and export. Hotmail is unknown? Gmail can use POP as an export mechanism.
Gmail - free forwarding to another account
Gmail - 3 months inactive before disabling, versus 1 month for Hotmail
? - folders/labels, we have one vote for Gmail labels being easier to use, but this may be more of a personal preference thing unless there is a real consensus.
Obviously a well-reasoned and professional opinion will follow.
Should we clutter up a interface just so that we have a function that we will only use twice a year? How about "Use as template" or "Add sender to Contact List." I'm sure there is no end to the buttons you could add to a interface but having the context menu for little used items are fine.
I never specified the method that should be used to add these features, only the method that should not be used as the exclusive method to add these features. You can put them in a drop down menu of a dozen rarely used features. You can add them as buttons. You can do a combination. You can do all sorts of things, so long as you don't make them completely inaccessible to many classes of users, by only putting them in the right-click menu.
...but having the context menu for little used items are fine.
No it isn't. Having functions made completely inaccessible to many users is not fine. It is shitty design you'd expect from some college student creating his first shareware project. If you still disagree, stop by a UI design conference some time and go up to any of the engineers. I'm sure they'll be happy to lynch you for such heresy.
Btw. If you switch the interface to "Classic" the Mark As Read buttons are placed up in the toolbar , obviously since you can't use the right mouse button. Good enough for those other cases when you don't have a choice in the matter.
Nope, because most users won't know that, thus they'll never discover it. They'll just click around trying to find the feature for 20 minutes before deciding it isn't there. Or, they'll look at the help and realize they can't use it and just go elsewhere.
Your arguments are summed up as "gee its not really that bad." You don't provide a single reason not to provide it as a regular drop down or a button or another control everyone can access. Congratulations on being an MS apologizer of the first water. The design stinks. Deal with it.
Gmail - Free POP support: It blows and no IMAP support. Used to be really buggy, I kind of doubt they put the effort to fix it.
POP is the only way I ever access my Gmail account and I've never noticed a problem with it. How does it "blow?" Also, don't you think free POP support and no IMAP support is better than Paid POP support and no IMAP support? This is a comparison of the two.
Gmail - prestige: Perhaps only for someone non-technical trying to judge. That's pretty sad to have an effect on your hiring practices.
Interesting assertion about the non-technical users, but I don't know of any support for it. Google is a more highly regarded brand according to most surveys in recent years. As for our hiring practices, it does make sense in a way. The types of technical decisions people make and their awareness of new technologies is pertinent to the job. A person with a Gmail account either just got it or has been beta testing it (cutting edge). A person with a Hotmail account may well be one of those people who chose something on its merits long ago and has not looked to see what the state of the art is. In any case, while it was probably not at all relevant to our final decision, you definitely should be aware of the impression your e-mail address makes professionally. If you have a silly name at an AOL account, be prepared to be regarded as technically incompetent. If you have a prestige account, like one associated with a cool OSS or research project, it definitely helps your chances.
Gmail - cross platform support: Google sure as hell doesn't like Opera. Perhaps only recently does Gmail work with it, though I had to degrade the interface previously. I know that many Google apps still complain and some will even boot you out if they detect Opera (colleage recently found that out when he tried changing browsers).
We're talking about Gmail, not Google in general. This is a comparison of two services, not everything done by their respective companies, or the old versions of products they used to have. Gmail lists Opera as a supported browser. Is there something specifically that does not work? MS lists Opera as an unsupported browser and provides it with the old, deprecated interface that this article talks about the replacement of. I'd say that is a win for Gmail, unless you have some specifics as to how Gmail is less useful than that.
All you who think MythTV is the answer need to take a class called Econ101. If everybody used MythTV to skip commercials, there would be no revenue generated as a result of those TV shows, and hence no shows at all.
Have you looked at the economics of the cable TV industry? It is not even close to a free market. The cost of cable programming is absurdly high compared to the cost of producing and delivering it because of government enforced, regional monopolies. I recall reading a study that showed if the cost of all TV programming currently on air was paid directly by users, and the shows were all burned to DVD and shipped that way, it would cost each household $12 a month to own a complete copy of everything. That is with absolutely no advertising money involved.
In any case, were advertisements all skipped, advertisers would start adding them at the bottom of the screen while the show is playing (some already have). When DVRs started blocking those too, they would insert placement ads in the programs for money (which they already do). Or, if by some miracle the price of cable actually reflected all their costs, they could raise the rates to cover the lack of ads. Movies make 70% of their money on DVD sales with no ads. Do you really think the lower budget television market could not survive doing the same?
But let me guess the replies.
Your guesses are very wrong and you have an overly simplistic view of the market that somehow neglects all the money people pay for cable subscriptions. Maybe you should take a class called Econ102.
While this is certainly close to true, it's not entirely accurate. GMail works very similarly across browsers, furthermore, not all features are supported on Safari or Opera, et al. The built-in google talk client does not work on Safari, for example.
I was talking about the e-mail features only. I believe the MSN chat function on the MS client is broken in alternative browsers as well. Are there ant GMail features that don't work (as opposed to integration with other Google services)?
Here is the revised list;
Gmail - disk space of 2.6+G versus 2G
Hotmail - attachment size, Hotmail claims to allow 10M attachments as the maximum, whereas Gmail claims 10M for the attachment and message combined. (Can anyone confirm the marketing is true?)
Gmail - Free POP support
Tie - I know Gmail has no graphic ads and some text ads and someone is claiming Hotmail has removed graphic ads now too for the free accounts. Can anyone confirm this or provide feedback on the number of ads and the manner they are shown?
Gmail - Spam, last I heard Gmail was winning the spam battle without the high false positive rate that has been plaguing Hotmail.
? - interface. Any interface designers with a clue taken a look at both of these?
Gmail - prestige. We interviewed a person with a Gmail address the other day and someone commented that she probably has a clue in technology. At an old job someone made the opposite comment with regard to an applicant with a Hotmail address.
Gmail - cross platform support. The e-mail functions of Gmail works the same way with Safari and Opera, while Hotmail degrades to the old interface in them. Gmail's supported browser list is much more extensive.
Gmail - language support. Gmail claims to support 41 unique languages (not variants) versus Hotmail's 31.
? address book import/export - Gmail supports CSV import and export. Hotmail is unknown?
The only reason they haven't put these restrictions on the DVRs yet is that they have to compete with TiVo.
If you had not noticed, Tivo signed a deal with Comcast to help develop and supply Tivo branded devices as Comcast DVRs, instantly making Comcast their biggest customer. Tivo is a partner to the big Cable companies now, not a competitor (which might be why we're seeing this stuff happening now). The writing was on the wall long before the deal was done as Tivo repeatedly refused to implement features that benefited their customers, but were opposed to the interests of the cable companies (skip ahead without an easter egg, commercial skip, export to DVD/VCD at a reasonable price, export to laptop in mpeg format, etc., etc.)
It seems to me that the cable companies only embraced DVRs in an attempt to kill them off, I imagine if they manage to drive TiVo out of business then they'll go back to their old tricks.
The way cable companies make money is by getting you to watch as many commercials as possible. This means getting you to spend more time watching ads and more time watching reruns with ads. The consumer buying a DVR wants to watch as few commercials and reruns as possible. These two goals are directly in conflict, which is why no one in their right mind should expect a good experience buying from a DVR manufacturer that is also their cable company or partnered with their cable company. They will give you the minimum features needed to keep you from going elsewhere, rather than the best feature set. The cable companies were smart to pay of Tivo, while they were still the only big player in the space. It redirects all the momentum in the space to ground, and gives them time to buy legislation to make sure only cable co. approved DVRs will work with "new improved" TV services. This space is ready for a revolution and a couple of new players, if only they can get by the cable company's monopoly leverage where they provide DVRs at under cost, while overcharging everyone for service to subsidize it.
How is a discussion of the interface to Hotmail with regard to Apple's standard mouse configurations, offtopic for an article about the new interface to Hotmail?
Okay, I don't have a hotmail account, although I do have a Gmail one. So how do the two stack up? From reading comments here and looking at public sources I see:
Gmail - disk space of 2.6G versus 2G
Hotmail - attachment size, Hotmail claims to allow 10M attachments as the maximum, whereas Gmail claims 10M for the attachment and message combined. (Can anyone confirm the marketing is true?)
Gmail - Free POP support
Tie - I know Gmail has no ads and someone is claiming Hotmail has removed them now too for the free accounts. Can anyone confirm this?
Gmail - Spam, last I heard Gmail was winning the spam battle without the high false positive rate that has been plaguing Hotmail.
? - interface. Any interface designers with a clue taken a look at both of these?
Gmail - prestige. We interviewed a person with a Gmail address the other day and someone commented that she probably has a clue in technology. At an old job someone made the opposite comment with regard to an applicant with a Hotmail address.
Gmail - cross platform support. Gmail works the same way with Safari and Opera, while Hotmail degrades to the old interface in them.
Gmail - language support. Gmail claims to support 41 unique languages (not variants) versus Hotmail's 31.
? address book import/export - Gmail supports CSV import and export. Hotmail is unknown?
Does anyone have any other comparative features or info or corrections for the above list?
The fact that there is a mechanism for this does not refute the previous poster's point. Right-clicking should never, ever be the only way to get to some functionality. I'm not sure I've ever seen a interface design or usability book that did not mention this. I think even MS's own UI design guidelines mention it. Right-clciking and selecting a menu option is a lot slower and less learnable than a button, but aside from that the important thing is relying upon multiple buttons breaks the interface for a wide variety of alternative input methods. Try doing that using a screen reader for the blind, or a stylus on a tablet, or even using MS's own voice recognition interface. Try it on a touch screen kiosk, using a control stick for people with palsey, or using a browser that does not support that function for one reason or another.
When people are lower level developers and don't have any real UI training and are creating an application for internal use or for a special purpose with limited audience, I can forgive this sort of thing. When one of the largest software development houses on the planet does it for a program they plan to roll to millions of the general public it is just fucking absurd. I want to know. Where does MS hire their UI people and why can't they manage to avoid basic mistakes that have been known to the industry for decades now?
What kind of an idiot moderator modded parent as "Troll"?
Probably the kind that isn't an idiot and is using a three button trackball on a mac, like I am. Any comment referencing lack of multi-button support on macs is almost certainly trolling. A few years ago, maybe they were just ignorant, but come on this is Slashdot where that crap was debunked in various articles once a week for a year straight.
By "open source software", do you refer to open source software as defined by Open Source Initiative [opensource.org]? If so, OSI's definition of open source software parallels Debian's definition of free software [debian.org]. I assume that you did not intend to make a distinction without a difference [wikipedia.org], so what definition of "open source" are you using?
By "open source software" I refer to software whose source is open. That is to say, software whose source is available for viewing and modification (with a wide variety of limitations that can be placed on redistribution of said modifications).
But is the part of Apple's software that integrates with Pantone technologies open source software as defined by OSI, or is color management one of the proprietary parts of Mac OS X?
You were originally talking about printing and Apple's printing component is CUPS, which is OSS by any definition of the term you can come up with. Not that it matters, as the whole thing is merely an example of a company that could license Pantone if there was a demand for it to be commercially licensed within an OSS project.
I contend that a distinction between inherent properties and artificial properties enforced by law is less than relevant for judging the relative merits of proprietary software vs. open source software as defined by OSI.
Then you should have argued against properties currently enforced by arbitrary laws in combination with licensing for some given component, not against inherent properties of OSS.
The right of end users to adapt software is inherent in open source software as defined by OSI.
Wheras it is specifically not an inherent property of OSS, while it is an inherent property of "free software" according to the Free Software Foundation which both predates the OSI and has a lot more influence in the software development community, from what I've seen. I think the distinction between "free and open" and "open" is a valuable one and trying to equate the two only leads to confusion. "Open source" simply means the source is open and trying to restrict that term to a subset of licenses seems absurd to me.
The point of DRM is to trigger the protection of the Digital Millennium Copyright Act, which applies in Slashdot's jurisdiction, and foreign counterparts.
No. The point of DRM is to "manage" people's rights for them. Providing a way to bring lawsuits under the DMCA is a mechanism of DRM. Media companies make negligible profit from DRM lawsuits directly. Claiming then, that the purpose of DRM is to create lawsuits under the DMCA seems irrational.
If we have open source software as defined by OSI running locally, and this software controls access to a copyrighted work using "keys stored either in hardware or on a remote location" stored in hardware or on a what is there to prevent the program from being modified to leak plaintext?
Do you actually want me to explain multi-key encryption to you? You encrypt data. The person who receives said data has no ability to do anything useful with it unless they get the right key in response to their key. Thus they have to access the key from another source, either embedded in hardware or from the internet. After that, they use the key to unlock the data. At that point nothing stops them from using the key to make a copy of the data, but that is true regardless of the software used to view it, since in the worst case scenario they can always point a camcorder at their screen. DRM simply makes it inconvenient, which having to retrieve keys is the most inconvenient part and is not associated with the given client software.
"Some localities" including the United States. Slashdot is on United States soil.
So? Software is not used only on US soil. People posting on Slashdot are not all in the US. Why does the locality of Slashdot's servers matter to this point?
You failed to address the analogy I presented or how you claimed it was flawed. I take it you concede the point then?
PANTONE Matching System on terms that are compatible with the four freedoms that define free software.
We were discussing Open Source Software, not "free" software. Do not confuse the two.
Or are you claiming that some major company that distributes free software has the resources to acquire Pantone Inc.?
Apple Inc. develops open source software, and certainly integrate with Pantone color schemes. I'm sure any number of commercial enterprises could license Pantone for an OSS project, if they so desired.
This sentence supports the assertion "That may not be not inherent in OSS in the future", not the assertion "That is not inherent in OSS."
Ha ha ha! Do you know what the word "inherent" means? I supported the assertion that it may not be in OSS future and that it is not inherent in OSS. Inherent means it is a fundamental property of OSS. It is not.
It is impossible for free software running on an end user's machine to correctly implement technical measures that allow an end user to play back a copy of a work but not to make and distribute more copies of the work.
It is impossible for closed software running on an end user's machine to correctly implement technical measures that allow an end user to play back a copy of a work but not to make and distribute more copies of the work.
The point of DRM is not to make it impossible, just to make it inconvenient. DRM as a concept is fundamentally flawed and will always be able to be bypassed. OSS makes it a little more cumbersome, requiring keys stored either in hardware or on a remote location.
Wouldn't free software that implements CableCARD have the ability to leak the plaintext signal?
Again you conflate free software with OSS software. We were talking about OSS. And it need have a leak no more than any closed source software.
And what about set-top video game consoles? PS2, PS3, Xbox 360, and Wii use a lockout chip business model. Most people aren't willing to buy a 27" PC monitor or a second PC for the TV room so that they can fit four players around one PC to play a multiplayer PC game, even if it could be the next Bomberman or Smash Bros.
Umm, you've lost me. What does this have to do with inherent traits of OSS?
Your analogy breaks because DRM is protected by law (17 USC 1201 and foreign counterparts), but blue user interfaces are not.
DRM is only protected by law in some localities (and technically is not protected at all since only the distribution of DRM bypass tools is banned, not the tools themselves or the action of using them). But my analogy is apt because we were talking about Fairplay which is a DRM scheme, just as CSS is. Both are protected by the same law. Fairplay and CSS are analogous and OSS and blue user interfaces are analogous. Show me how that analogy fails.
If there's no specific rule against it, it falls under the elastic clause of "Behavior unacceptable of a student of XXXX".
Exactly, which of course is why the school will lose this lawsuit. Businesses can make all the rules they want, but if they enforce them unequally then, they are going to lose in court. I'm sure people will be able to dig up plenty of other photographic evidence of other students and faculty drinking and the fact that they only went after this one woman, will result in much the same result as if they ahd no rule in the first place.
Slashdot Mirror
Because there is a big difference between making the claim that a machine is "Linux Compatible" and actually shipping with a tested version pre-installed as a demonstration that there are drivers for all components
So Apple sued the guy who disclosed this Quicktime vulnerability? If that happened, I never heard about it. In fact, I work i the security industry and very, very rarely hear about any lawsuits, which is why they are news when they do happen.
Not unless the companies start making it (public) policy that they WILL NOT sue you as long as you disclose a vulnerability to them first, and give them a reasonable time to fix it before going public.Why? Would such a statement stop them from later doing it? In general companies don't sue over vulnerability disclosures, no matter whether they are immediate, or if the vendor is given time. The reason security researchers tend to give companies time to fix things is because that is what they think is best for security, overall.
I think that'll never happen though, and the only way to safeguard a hacker is to make legislation against those type of lawsuits.That doesn't really work. Basically you can sue anyone for anything in the US (with very few exceptions). I don't see the need for one here since I very rarely, if ever, hear about anyone being sued for disclosing bugs.
Actually, security through obscurity is very functional and useful as part of a security scheme. Your password is security through obscurity. Why don't you just give it to everyone if it makes no difference?
In the intervening months, you have a live, exploitable hole sitting there ripe for attack!And if you disclose the wrong vulnerability to the general public you have a live, exploitable hole that everyone knows about sitting there ripe for attack. Which is better?
Responsible disclosure is simply evaluating what is best for the security of users and disclosing i that manner. n some cases, the best thing for overall security is immediate, public disclosure to pressure the vendor into fixing the hole more quickly and to give users a chance to work around the vulnerability. In other cases, where the vendor is responsive, and ther is no easy way to mitigate the vulnerability for the end user, immediate disclosure increases the risk to users with no real benefit.
I say, damn the consequences. Report as soon as possible no matter who it embarrasses.Who is embarrassed is immaterial. Ignoring the likely consequences of you disclosure method, however, is irresponsible, which is why the alternative is called "responsible disclosure."
It'll either put more pressure on them to fix the bugs faster...In many cases the vendor is very motivated and goes to work with all their resources immediately. Take a look at the OmniWeb vulnerability published by the MOAB project. Omnigroup implemented a fix within a day and had it available for download, but they do the same thing for bugs disclosed to them privately. All the immediate disclosure did was give hackers more time to exploit the problem before the fix reached users. Disclosing a vulnerability to the public before sending it to a responsible and security minded development team is good for no one but blackhats. Also, rushing vendors to write code faster, can result in more bugs in said code, including other vulnerabilities or or bugs.
...or push users to more secure platforms where security fixes don't take months and are usually found before their ever exploited in the wild.Please. Most users will not switch platforms because of security issues and many are locked into MS's desktop monopoly by some software they absolutely need and price constraints. The vast majority of users never even hear about security vulnerability disclosure in the first place.
Here's a tip for you from someone who does work in the security industry. If you're looking for a job in the field, don't expose your irresponsible ideas about disclosure if you want a chance at being hired somewhere respectable.
All expression is protected by the constitution. The only issue is when one person's right to express themselves comes into conflict with another person's constitutionally protected right. For example, if I tell my crime syndicate goons to go kill you, and I'm caught, I still go to jail for conspiracy to commit murder, even though my only act was expression. That is because my right to free expression was trumped by your right to live.
The question then, is: "does some given 'hate speech' conflict with another right, such as the right to religious freedom?" I'd say it does only when it is likely to interfere with that right, which most hate crime laws use the probability of some violent action, being the determining factor. Is it reasonable to assume people would act violently against Scientologists or Christians or Muslims, because of what I said?
Here's a puzzler for you. Suppose I found a religion with two basic principals. First, we will use our magic powers via meditation to make everyone who is not a member either become a member or die of cancer by the invisible hand of our god. Second, in order to be saved, we must spread the word and tell everyone of our religion.
What happens to the application of CA law to Scientology in that instance. Sure a person is threatening another religion, in fact all other religions... but it is their right under both free speech and freedom of religion to do so and to stop them would be to deny them both those rights for the sake of theoretically protecting a different religion from a threat which is not scientifically credible. How does California's law have any claim to constitutionality in such a circumstance?
Before I get into this rebuttal, I would like to point out that I believe your confusion originated because you learned computing on a Macintosh.
Umm, I did not learn computing on a Macinstosh. I Learned on a Commadore64, then an Apple2C, then a variety of computers in school. In fact, the first computer I ever owned personally was a hybrid machine containing both a 66Mhz PPC chip and a 66Mhz 486, which had a built in KVM. I think this actually makes me one of the very few people to have started off with no mac or PC bias as I spent a lot of time instantly able to switch between the two OS's. The input devices I used were the keyboard and a four button track ball (the olde fashoined kind, like from centipede).
The precise procedure is as follows:
That does not work in my version of OpenOffice. You have to highlight the word first. As I mentioned, I don't have a Hotmail account for testing, but you seem to have missed the point. The difficulty that arises is not in the step where one must highlight the word, but where one must either hold down the button while scrolling down the list, or, use both the right and left buttons for the same procedure.
You're right, but you have set up the dichotomy wrong. The comparison really should be between new users and the so-called computer literate. You do not even need to be close to expert for the context menu to be faster, in this case.
It is not a dichotomy. What a given person considers an "expert" is very relative. Since this software (hotmail) is targeting the general populace, I'll ask you a question, "have you ever watched a usability study where the users were the general public?" If you have, you would probably not consider the use of and learning of the right mouse button to be a non-issue. It is the single, number one, most common usability issue in every computer usability study with the general public I've personally seen, and in almost every one I've read.
Let's run your example:
I actually did not give an example, but I did mention use of a button. The point I was bringing up is that for the general user, there are methods that are as fast if not faster, when actually used, rather than in the theoretical use cases you show. For example, you fail to account for people selecting the wrong word, or hitting the wrong mouse button when trying to use your context menu, which is a common case and which slows overall usage. You did not account for users who will click both buttons simultaneously all the rime, but who tend to unconsciously hit the left button more commonly. You did not account for users who will not find this function at all and who will go get a dictionary and correct by hand.
I mentioned a button because it usually results in static behavior. You don't have a menu that will go away if you accidentally click. There is also the use case of a spelling checker that is run on command and which asks the user about each misspelled word. In some cases, this is actually faster.
My point is, context menus are for expert users in front of a Windows box. If you're targeting the general public (like hotmail) it should not be the primary interface for a function and it should certainly not be the only interface.
Granted, but I don't care. I know that you started by replying in regards to hotmail. I, on the other hand, am not here to extol the virtues (or berate the faults) of hotmail. I'm here because you made a very broad incorrect declaration: "Right-clciking and selecting a menu option is a lot slower and less learnable than a button".
I made that in the context of a discussion about hotmail and with regard to a class of users. Right-clicking is almost always going to be less learnable in the general case than a button, except for very particular user groups. As for speed, that depends entirely upon the use case and there was one under discussion.
One cav
The whole point of this discussion was that they should not be the only way to access the function, as they are in this new version of Hotmail. They are fine as a secondary mechanism.
Well I was talking buttons.That was your incorrect assumption.
As for menus, you first have to select which menu you need from the horizontal list of menus (file, edit, view, etc) then you go down a vertical menu. With context menus you right click and the menu you want is right there, no searching in 2 dimensions.Okay, since you seem to have never looked into the topic, here are the general usability rules for menus and the reasons for them. If you have 7 or fewer controls, use buttons. If you have fewer than 64 controls, use menus, with no more than 8 top level menus. If you have more than 15 items in a menu, you'll have problems. If you have nested menus, you'll have problems.
Now right-click menus are special because of the usability concerns they bring up. They should never, ever be the only way to access something, so they are always duplicating something you have elsewhere. They can be duplicating items in a nested menu, if you don't have a better option. They should always be customizable, since they are repeats, not primary access controls, and the user always knows their workflow better than the designer. If at any point you have more than about 12 items in your context menu, you will have serious problems with usability.
As for learnability, sometimes it's better to sacrifice learnability for power.I agree. I disagree that this is one of those cases. This is a Webmail service. It targets a wide range of complete novices and the general public including people with disabilities, or who are using cell phones, and many other cases that cannot be accounted for.
It only takes 5 seconds to explain to someone what the right click button is for, and they keep that with them for the rest of their lives.Spoken like someone who has never watched a usability test. Average users forget functions they do not use all the time. A lot of users check their e-mail once every few weeks. Just telling them where the right-click button is and what it is for is not enough and who exactly will be telling users of hotmail this?
They'll save much more time using the context menu than they spent learning how to use it.No, they simply won't learn how to use it and will not use any function only there. For a reasonable subset of users (novices, disabled, phone users, tablet users, voice recog users, some alternate browser users, etc. it will be as though that function is not even there... and that is a big design failure.
Hmm, good question. It is an OS X system service called "BibliographyService." It may have come with BibDesk, but it does not seem to be grouped with the other services from there. It may be a stand alone service I grabbed somewhere.
True, but that's not what we're talking about. We're talking about applications that run via a Web browser and integrate with a Web service (Google Docs), but which also run locally without Web access, albeit with some features disabled. It is important to note, we were speaking about the desktop metaphor being dead, and when your app is running locally in a browser, that does seem to be the case to a significant extent.
For example, gmail has a nice view run locally in the browser.I'm afraid I have no idea what you were trying to say with that sentence. Could you please be a little clearer.
You cannot send or receive email if you are not online.So? The point is to allow you to compose messages in Gmail when offline. More importantly, for applications whose primary purpose is not communication via the Web (games, photo editor, word processor, spreadsheets, calculators, etc.) it will allow them to be functional offline, only adding functionality when online.
Desktop is NOT dead.The desktop is not dead. The desktop is threatened as a control metaphor, by the browser. I, personally, don't think Redhat's plan is sound or their vision is accurate. I never argued that they did. I merely pointed out the problems with the assertions that Web applications are not useful because they don't function when offline. Since they are moving towards a more hybrid approach, that is a dated view.
I also understand where Redhat is coming from. The desktop OS has stagnated. Most users still do not have (and will not for the foreseeable future) have spellchecking available in all applications. That is just sad. Any possible way to undermine MS's monopoly and add functionality despite their stubborn refusal to move forward gets developers excited. Anything that removes user's dependancy on Windows is a plus for me.
The mozilla team has already talked about Firefox 3's upcoming support for running online apps while offline, as a sort of hybrid, but still within the browser. Just do a search for "web applications offline' and you'll find dozens of articles including how-to sites from tool providers for making Web apps that will function offline right now.
To user the desktop metaphor is not dead when offline.I'm not sold on Web applications. I'm not sold on a strategy of bypassing MS by building everything on top of them. I'd rather see cross platform applications with internet capabilities, or hybrid solutions, that still allow me to take advantage of the benefits of the OS. From a practical standpoint, however, my automatic bibliography formatting service allows me to automatically format bibliography references right now using Google Docs, but I can't use the same functionality in Wordpad or in MSWord for that matter; so in some ways online apps are already allowing me to bypass the limitations of Microsoft's OS.
Actually, the procedure for using it is: highlight the word (usually by double clicking), then right click, then select correct spelling from the provided list, then release the button. In general, the workflow of highlighting a word, then hitting a button and navigating a dialogue in a standard location is faster for new users and slower for expert users, in that instance, but you're failing to account for the fact that it is a special case where there are very, very few options in the contextual menu. As the number of items in the contextual menu gets larger, the operation becomes slower and slower, while the traditional button option remains the same speed. Now this is partially mitigated on a WebUI because the buttons are not always in a persistent location.
As to "learnability" contextual menus are a nonstandard interface item compared to buttons, and one that has no persistent clue. If you don't know you can right click on something, looking at the screen provides you with no clue to that, whereas just looking at the screen a user can see a button for the same function, and may, thus, experiment or investigate and learn what that button does, thus learning to use the feature.
Besides, when someone starts learning to use a computer on a Windows box, they will start right clicking on everything to learn their options.For some advanced groups of users this is true, but it is not even close to true for average users in usability tests. The number one usability issue encountered with average users is they don't understand right and left clicking. Some will ask for every button/clickable every time. Some choose randomly. Some always click both buttons simultaneously with somewhat random results. In general, novice users do not ever find and intentionally avoid features in right-click contextual menus. For those reasons such a usage is very inappropriate for a Web mail client that is going to be rolled out to the general public including very novice users.
Context menus are great as a secondary way to access common functions. They are terrible as a primary way for the reasons I listed.
Buttons are always there, so there's going to be a lot more of them, most of which are irrelevant.Buttons are fine and menus are fine (conceptually, implementations can be poor). Users understand that they exist and can look through them for the function they want.
They could also be anywhere on your screen, a context menu is linear.Umm, linear? How is a context menu more linear than say a drop down menu? More importantly, how is it more usable?
So it's going to be a lot easier and faster to find the option on the context menu than pretty much anywhere else.Well it certainly isn't going to be faster to find for a person using a screen reader, since they will never see it. As for everyone else, as I said I'm not opposed to context menus, simply to functions available only by the context menu. A well implemented context menu duplicates certain very common functions and is customizable so the user (who is the only one who knows his own workflow) can further streamline it. They are terrible, however, when used as the primary interface because they remove all flexibility from the interface excluding all the people in situations like those I listed. They also suffer from poor learn-ability and are confusing to novices.
As for less learnable, how do you even quantify that?Generally via usability testing with software that tracks what a user does with an interface and how long it takes them both to accomplish tasks the first time and then subsequent times. For context menus as exclusive interfaces, however, testing has shown over and over and over again that they are a terrible idea. Alternate interfaces can't use them at all. Novice users often never find those functions or accidentally trigger them. One of the single biggest usability problems with computers today is users that don't know if they should right-click or left-click or don't even distinguish and always click both at once resulting in random results. It is not like this is news. This was exposed as a huge problem in almost all use cases decades ago and has been a standard feature of usability texts and UI design instruction for nearly as long. It is on the "top 10 UI design blunders" list.
If you're programming an interface to a professional CAD application, well your users will figure it out and very few users will need alternative input devices (except those using a stylus and board). If, however, you're programming a Web mail client that will be targeting brand new users it is a disaster. Imagine if you were a disabled person and went to the Web page of the biggest software maker in the US, only to find that their Web mail did not work for you for common tasks, unless you found some hidden setting that would switch it back to their old, deprecated interface? You really think that is okay or good design, when the work around is so easy?
I'm sorry but I've worked in UI design and usability testing, though not for several years. I keep up on the literature. Putting a function only in a right-click menu is a mistake for the clueless novice, not for professionals.
The list updated with misc additions for others who replied:
Obviously a well-reasoned and professional opinion will follow.
Should we clutter up a interface just so that we have a function that we will only use twice a year? How about "Use as template" or "Add sender to Contact List." I'm sure there is no end to the buttons you could add to a interface but having the context menu for little used items are fine.I never specified the method that should be used to add these features, only the method that should not be used as the exclusive method to add these features. You can put them in a drop down menu of a dozen rarely used features. You can add them as buttons. You can do a combination. You can do all sorts of things, so long as you don't make them completely inaccessible to many classes of users, by only putting them in the right-click menu.
...but having the context menu for little used items are fine.No it isn't. Having functions made completely inaccessible to many users is not fine. It is shitty design you'd expect from some college student creating his first shareware project. If you still disagree, stop by a UI design conference some time and go up to any of the engineers. I'm sure they'll be happy to lynch you for such heresy.
Btw. If you switch the interface to "Classic" the Mark As Read buttons are placed up in the toolbar , obviously since you can't use the right mouse button. Good enough for those other cases when you don't have a choice in the matter.Nope, because most users won't know that, thus they'll never discover it. They'll just click around trying to find the feature for 20 minutes before deciding it isn't there. Or, they'll look at the help and realize they can't use it and just go elsewhere.
Your arguments are summed up as "gee its not really that bad." You don't provide a single reason not to provide it as a regular drop down or a button or another control everyone can access. Congratulations on being an MS apologizer of the first water. The design stinks. Deal with it.
POP is the only way I ever access my Gmail account and I've never noticed a problem with it. How does it "blow?" Also, don't you think free POP support and no IMAP support is better than Paid POP support and no IMAP support? This is a comparison of the two.
Gmail - prestige: Perhaps only for someone non-technical trying to judge. That's pretty sad to have an effect on your hiring practices.Interesting assertion about the non-technical users, but I don't know of any support for it. Google is a more highly regarded brand according to most surveys in recent years. As for our hiring practices, it does make sense in a way. The types of technical decisions people make and their awareness of new technologies is pertinent to the job. A person with a Gmail account either just got it or has been beta testing it (cutting edge). A person with a Hotmail account may well be one of those people who chose something on its merits long ago and has not looked to see what the state of the art is. In any case, while it was probably not at all relevant to our final decision, you definitely should be aware of the impression your e-mail address makes professionally. If you have a silly name at an AOL account, be prepared to be regarded as technically incompetent. If you have a prestige account, like one associated with a cool OSS or research project, it definitely helps your chances.
Gmail - cross platform support: Google sure as hell doesn't like Opera. Perhaps only recently does Gmail work with it, though I had to degrade the interface previously. I know that many Google apps still complain and some will even boot you out if they detect Opera (colleage recently found that out when he tried changing browsers).We're talking about Gmail, not Google in general. This is a comparison of two services, not everything done by their respective companies, or the old versions of products they used to have. Gmail lists Opera as a supported browser. Is there something specifically that does not work? MS lists Opera as an unsupported browser and provides it with the old, deprecated interface that this article talks about the replacement of. I'd say that is a win for Gmail, unless you have some specifics as to how Gmail is less useful than that.
Have you looked at the economics of the cable TV industry? It is not even close to a free market. The cost of cable programming is absurdly high compared to the cost of producing and delivering it because of government enforced, regional monopolies. I recall reading a study that showed if the cost of all TV programming currently on air was paid directly by users, and the shows were all burned to DVD and shipped that way, it would cost each household $12 a month to own a complete copy of everything. That is with absolutely no advertising money involved.
In any case, were advertisements all skipped, advertisers would start adding them at the bottom of the screen while the show is playing (some already have). When DVRs started blocking those too, they would insert placement ads in the programs for money (which they already do). Or, if by some miracle the price of cable actually reflected all their costs, they could raise the rates to cover the lack of ads. Movies make 70% of their money on DVD sales with no ads. Do you really think the lower budget television market could not survive doing the same?
But let me guess the replies.Your guesses are very wrong and you have an overly simplistic view of the market that somehow neglects all the money people pay for cable subscriptions. Maybe you should take a class called Econ102.
I was talking about the e-mail features only. I believe the MSN chat function on the MS client is broken in alternative browsers as well. Are there ant GMail features that don't work (as opposed to integration with other Google services)?
Here is the revised list;
If you had not noticed, Tivo signed a deal with Comcast to help develop and supply Tivo branded devices as Comcast DVRs, instantly making Comcast their biggest customer. Tivo is a partner to the big Cable companies now, not a competitor (which might be why we're seeing this stuff happening now). The writing was on the wall long before the deal was done as Tivo repeatedly refused to implement features that benefited their customers, but were opposed to the interests of the cable companies (skip ahead without an easter egg, commercial skip, export to DVD/VCD at a reasonable price, export to laptop in mpeg format, etc., etc.)
It seems to me that the cable companies only embraced DVRs in an attempt to kill them off, I imagine if they manage to drive TiVo out of business then they'll go back to their old tricks.The way cable companies make money is by getting you to watch as many commercials as possible. This means getting you to spend more time watching ads and more time watching reruns with ads. The consumer buying a DVR wants to watch as few commercials and reruns as possible. These two goals are directly in conflict, which is why no one in their right mind should expect a good experience buying from a DVR manufacturer that is also their cable company or partnered with their cable company. They will give you the minimum features needed to keep you from going elsewhere, rather than the best feature set. The cable companies were smart to pay of Tivo, while they were still the only big player in the space. It redirects all the momentum in the space to ground, and gives them time to buy legislation to make sure only cable co. approved DVRs will work with "new improved" TV services. This space is ready for a revolution and a couple of new players, if only they can get by the cable company's monopoly leverage where they provide DVRs at under cost, while overcharging everyone for service to subsidize it.
How is a discussion of the interface to Hotmail with regard to Apple's standard mouse configurations, offtopic for an article about the new interface to Hotmail?
Okay, I don't have a hotmail account, although I do have a Gmail one. So how do the two stack up? From reading comments here and looking at public sources I see:
Does anyone have any other comparative features or info or corrections for the above list?
Well, all macs now ship with either multibutton (mighty)mice or trackpads that support the same functionality via chording. So, pretty good.
The fact that there is a mechanism for this does not refute the previous poster's point. Right-clicking should never, ever be the only way to get to some functionality. I'm not sure I've ever seen a interface design or usability book that did not mention this. I think even MS's own UI design guidelines mention it. Right-clciking and selecting a menu option is a lot slower and less learnable than a button, but aside from that the important thing is relying upon multiple buttons breaks the interface for a wide variety of alternative input methods. Try doing that using a screen reader for the blind, or a stylus on a tablet, or even using MS's own voice recognition interface. Try it on a touch screen kiosk, using a control stick for people with palsey, or using a browser that does not support that function for one reason or another.
When people are lower level developers and don't have any real UI training and are creating an application for internal use or for a special purpose with limited audience, I can forgive this sort of thing. When one of the largest software development houses on the planet does it for a program they plan to roll to millions of the general public it is just fucking absurd. I want to know. Where does MS hire their UI people and why can't they manage to avoid basic mistakes that have been known to the industry for decades now?
Probably the kind that isn't an idiot and is using a three button trackball on a mac, like I am. Any comment referencing lack of multi-button support on macs is almost certainly trolling. A few years ago, maybe they were just ignorant, but come on this is Slashdot where that crap was debunked in various articles once a week for a year straight.
By "open source software" I refer to software whose source is open. That is to say, software whose source is available for viewing and modification (with a wide variety of limitations that can be placed on redistribution of said modifications).
But is the part of Apple's software that integrates with Pantone technologies open source software as defined by OSI, or is color management one of the proprietary parts of Mac OS X?You were originally talking about printing and Apple's printing component is CUPS, which is OSS by any definition of the term you can come up with. Not that it matters, as the whole thing is merely an example of a company that could license Pantone if there was a demand for it to be commercially licensed within an OSS project.
I contend that a distinction between inherent properties and artificial properties enforced by law is less than relevant for judging the relative merits of proprietary software vs. open source software as defined by OSI.Then you should have argued against properties currently enforced by arbitrary laws in combination with licensing for some given component, not against inherent properties of OSS.
The right of end users to adapt software is inherent in open source software as defined by OSI.Wheras it is specifically not an inherent property of OSS, while it is an inherent property of "free software" according to the Free Software Foundation which both predates the OSI and has a lot more influence in the software development community, from what I've seen. I think the distinction between "free and open" and "open" is a valuable one and trying to equate the two only leads to confusion. "Open source" simply means the source is open and trying to restrict that term to a subset of licenses seems absurd to me.
The point of DRM is to trigger the protection of the Digital Millennium Copyright Act, which applies in Slashdot's jurisdiction, and foreign counterparts.No. The point of DRM is to "manage" people's rights for them. Providing a way to bring lawsuits under the DMCA is a mechanism of DRM. Media companies make negligible profit from DRM lawsuits directly. Claiming then, that the purpose of DRM is to create lawsuits under the DMCA seems irrational.
If we have open source software as defined by OSI running locally, and this software controls access to a copyrighted work using "keys stored either in hardware or on a remote location" stored in hardware or on a what is there to prevent the program from being modified to leak plaintext?Do you actually want me to explain multi-key encryption to you? You encrypt data. The person who receives said data has no ability to do anything useful with it unless they get the right key in response to their key. Thus they have to access the key from another source, either embedded in hardware or from the internet. After that, they use the key to unlock the data. At that point nothing stops them from using the key to make a copy of the data, but that is true regardless of the software used to view it, since in the worst case scenario they can always point a camcorder at their screen. DRM simply makes it inconvenient, which having to retrieve keys is the most inconvenient part and is not associated with the given client software.
"Some localities" including the United States. Slashdot is on United States soil.So? Software is not used only on US soil. People posting on Slashdot are not all in the US. Why does the locality of Slashdot's servers matter to this point?
You failed to address the analogy I presented or how you claimed it was flawed. I take it you concede the point then?
We were discussing Open Source Software, not "free" software. Do not confuse the two.
Or are you claiming that some major company that distributes free software has the resources to acquire Pantone Inc.?Apple Inc. develops open source software, and certainly integrate with Pantone color schemes. I'm sure any number of commercial enterprises could license Pantone for an OSS project, if they so desired.
This sentence supports the assertion "That may not be not inherent in OSS in the future", not the assertion "That is not inherent in OSS."Ha ha ha! Do you know what the word "inherent" means? I supported the assertion that it may not be in OSS future and that it is not inherent in OSS. Inherent means it is a fundamental property of OSS. It is not.
It is impossible for free software running on an end user's machine to correctly implement technical measures that allow an end user to play back a copy of a work but not to make and distribute more copies of the work.It is impossible for closed software running on an end user's machine to correctly implement technical measures that allow an end user to play back a copy of a work but not to make and distribute more copies of the work.
The point of DRM is not to make it impossible, just to make it inconvenient. DRM as a concept is fundamentally flawed and will always be able to be bypassed. OSS makes it a little more cumbersome, requiring keys stored either in hardware or on a remote location.
Wouldn't free software that implements CableCARD have the ability to leak the plaintext signal?Again you conflate free software with OSS software. We were talking about OSS. And it need have a leak no more than any closed source software.
And what about set-top video game consoles? PS2, PS3, Xbox 360, and Wii use a lockout chip business model. Most people aren't willing to buy a 27" PC monitor or a second PC for the TV room so that they can fit four players around one PC to play a multiplayer PC game, even if it could be the next Bomberman or Smash Bros.Umm, you've lost me. What does this have to do with inherent traits of OSS?
Your analogy breaks because DRM is protected by law (17 USC 1201 and foreign counterparts), but blue user interfaces are not.DRM is only protected by law in some localities (and technically is not protected at all since only the distribution of DRM bypass tools is banned, not the tools themselves or the action of using them). But my analogy is apt because we were talking about Fairplay which is a DRM scheme, just as CSS is. Both are protected by the same law. Fairplay and CSS are analogous and OSS and blue user interfaces are analogous. Show me how that analogy fails.
Exactly, which of course is why the school will lose this lawsuit. Businesses can make all the rules they want, but if they enforce them unequally then, they are going to lose in court. I'm sure people will be able to dig up plenty of other photographic evidence of other students and faculty drinking and the fact that they only went after this one woman, will result in much the same result as if they ahd no rule in the first place.