Maybe, but there's a big difference in hearing the "geek in the family" talking about yet another tech subject without really hearing about it anywhere else, vs. visiting a web site only to find it taken down and replaced with a message about SOPA.
My (and many people's) individual words will not have near the impact that seeing giant organizations cooperatively taking action -- by giving up a day's worth of business -- in opposition to something.
That's not to say that we shouldn't try to educate others. But something like this will go so much further -- it will hit deeper and broader.
Very likely that they already explained to their relatives after bringing it up.
I even heard that people in IT have said that other people they work with have no idea about the ramifications of SOPA and many other anti-Internet bills.
There is surprisingly little written about good API design. Maybe it's because the important things to say have already been said, but I have my doubts that that is the reason.
I suspect it's partly because of the difficulty involved in measuring the quality of a given API's design. How do you separate the success resulting from the usefulness or popularity of the technology from the design of the API?
That was the first thing I though on starting to read this. How do they know they've actually got it right? Feedback from users?
No, there is no conventional standard for auto-complete and you would have to be able to determine whether or not the user was actually trying to employ a/c functionality versus typing a term that they've already brought to the forefront of their action. Auto-complete interrupts this mental workflow and affects the UX in a negative manner. It's like continuously prompting a person who has difficulty with stuttering. After awhile they'll find you too difficult to talk to and go back to drinking beer and watching TV.
One aside is the convention of time/date/location that you'll find everywhere. For whatever reason someone needs to capture the information from the Andorrans to the inhabitants of Wallis and Futuna. I can't fight people that include over 200 options for countries and territories when this info could be ascertained and captured via other methods, but people already have a mental map of where their options are in these lists, so if you really need to, then go ahead. iOS has the best solution for this. Also, a select is a part of CRUD, so please don't use it for navigation.
The solution that I like to employ is an unordered HTML list, with the items bricked in equal size, separated uniformly right and bottom and floated left. You can see this when you look at Google+'s circles. The user knows to read from left to right (assuming western conventions) and can navigate top to bottom with the ease of the mouse without making commitments. I currently do this with a list of ~250 options and employ ajaxy magic to capture the user's actions. I assist the user by alphabetizing the list so that they'll be able to mentally map their position as well as curated and separately displaying the most popular option at the top of the list, much like US-based website will do when displaying "United States" as the first option in their select. If displaying on a mobile device, I would recommend displaying in a one-column list; if a user can navigate Twitter, they'll have no problem with scrolling down to find their selection because they've already been trained to do so and it'll come as second nature. (which is why is good practice to adopt conventions from popular applications. Why fight it?)
Another option that I've found helpful i to employ pathways when too many options with similar names can cloud the user's mental map. It's ok to break up a form into logical step-by-step pieces. You gain the user's trust by preempting tedious actions. Intersticial pages, not pop-ups, are ok if the user understands where you are taking them and for the tricky parts, some reassuring copy can do the trick. People read; just go through Amazon's checkout process a couple of times over the course of a week. You may forget a step, but they're right there to help you without employing navigation or CRUD devices on the screen.
tl;dr: just put the options in a list as ajax buttons or checkbox-activated text. Keep it simple and organized and don't play hide and go seek with the user.
It's at times like these where I wonder if the Node.js community overhypes their "webscale" framework. Evented or not, if your server doesn't have the resources to serve up the requests, things are going to break in fun ways.
I guess they forced the end of the session to allow non-session authentication, for example for an Client accessing an RESTful API.
I didn't found anything about this, but when you look at the related commit in rails (https://github.com/rails/rails/commit/66ce3843d32e9f2ac3b1da...) they also removed the white listing an all non html-requests ("content_mime_type.verify_request?"). So any (api) client modifying XML or JSON resources of an rails app would not be allowed to do so, because of the need to provide the authentication token. Which isn't available for an API client, because there is no session.
So instead of throwing an exception to prevent an CSRF-attack they just kill the session to prevent authentication by this session. For an api client this is no big deal, because normally it authenticates with per request credentials.
If you don't feel/have the need to support non session authentication, my guess is you could simply overwrite the handle_unverified_request method in your application controller to throw an exception again. But I would wait for further explanation by the rails core team.
