stephth

a contemptible or objectionable person.

It's appropriate.

EDIT: here's full context per JackWebbHeller's request:

@dhh The Sharebooster site is serving even more images straight off the Highrise server: http://yfrog.com/oddh4zoj . Fucking scumbags.

Curebit not only screwed up bad, but they kept digging deeper and deeper in their debate. I'm really glad they're being called for with directness and severity. You should be too.

I worked on this set of visualizations on traffic in the center of Madrid a few years ago: http://trsp.net/cow

I found the numbers stunning. Some avenues had an average of 100k vehicles driving through daily.

I've since moved to San Francisco, and find that traffic in US cities is less painful, the cities' grids and sidewalks are better prepared. But still, it's ridiculous how much freedom cars are given. A few months ago traffic in Valencia St, one of the nicest streets in the Mission, was cut off, and it was bliss to take a walk there, even though the street was super crowded. At least some streets should always be traffic free, I dont think it's that much effort to ask, and the benefits in quality of living are tremendous.

It's interesting to read an experience where Node's performance largely pays off when building traditional sites. I've often read that Node's performance really only pays off when building realtime apps. Maybe I misinterpreted, perhaps it was meant more as the large set of features provided by frameworks like Rails/Django transcend Node's performance boost?

What does that mean exactly? Could you describe it? Does it sound like physically outside but you realize by logic that it "didnt happen", or is it clear right away that it's an imaginary sound?

I appreciate that it isn't too much of a shibboleth for you and that you could stick around, I'd be interested in knowing a little more about the literature you mentioned. Do they propose specific techniques to usability testing? Which one do you use? In my case it's watching friends/family/expo attendants interact with the app but I don't have much of a formulated technique, it's casual, but I'd be interested in knowing more (and in the process I may be convinced that I should actually read that literature).

One absolutely can not depend on users to assume that needed functions can be found in invisible items.

I don't think it's that simple. It depends on the context and on the target. On a professional tool targeted to software developers like github, and being a consistent pattern, then yes, I think you can depend on that. If on the other hand you use that pattern in a context where it's not frequently seen, and/or it's not a consistent pattern in your app, you probably shouldn't depend on it, no.

I really, really like this idea as a solution to fix possible hidden rollovers usability issues. Like the best ideas it sounds obvious once you hear it. If it is well executed (I would imagine something clean and simple yet recognizable like a point within a circle) and when/where it does work, then - like you said - it's a solution that works for both touch and rollover, and that's exciting too.

I misinterpreted your "What is the affordance of invisibility?" question as in "what are the benefits of invisibility?". Thanks for clarifying. I didn't know (and couldn't find) that specific definition of affordance. Is it a technical term?

Just seeing the interface component intrinsically describes its use. This is not possible for invisible components, therefore they have no affordance at all.

It's true. But this isn't very relevant to this article is it? we're talking about hidden items, not invisible items.

"Your brain is able to predict that if you don't see it, it might very well be rollover-only." This statement is so wrong I don't even know how to react to it or steer you away from this sort of thinking. I'm just completely taken aback. Not trying to be argumentative or anything, but no no no no no. No, the user is not going to intuit that the function must be invisible because he can't see it. Arg.

You can be argumentative by showing some reasoning to your opinion. That would help. What is wrong with my statement in your perspective? Either way maybe I can clarify further. I don't think intuition and experience (prediction) are separated. I strongly believe in Jeff Hawkin's theory [1]. All we do is this: we learn things, and later, based on what we learned, we make predictions, and act based on those predictions. And I think this is very relevant with interface design. If a certain pattern becomes frequent, people will become familiar with that pattern, and that pattern will become more usable. The drawback to that is that some patterns may be crappy, but it's still something I take into consideration in making interfaces, consciously or not. Of course you can try to ignore all that and think completely outside of the box - I've tried it a few times and while it's a lot of fun, a lot of people get disoriented for longer, even though the concepts are simple. Think about how fast the learning curve in a simple 2D platform game is. Their rules are quite alien to our real world (super high jumps without dying, hitting bricks throws a mushroom, etc etc) but what makes that learning curve really fast is that we've learned it again and again. It wasn't easy the first time, but 2D platform are a familiar pattern; my generation has learned it since early age, with Mario and Sonic. Intuitive is, in a way, anything that feels familiar. And a familiar pattern in github is hidden functionality that appears with a rollover. If I don't see something, I can guess that it may show up when I so a rollover.

Here is the proof. Usability testing.

How does usability testing prove that "the user is not going to intuit that the function must be invisible because he can't see it"? Can you elaborate? Have you done the testing or have you read about it being statistically proven otherwise?

[1] http://www.ted.com/talks/jeff_hawkins_on_how_brain_science_w... (to be clear I'm alluding to the part about prediction)

Here's how I see it (and as you'll see, I'll be taking various assumptions. Please feel free to tell me I'm wrong (but make a case)):

We like to have everything at hand, but we also like (it's more like a need actually) to focus. Too many elements are a distraction. That's basically why we put things in boxes even if we don't intend to transport them anywhere: out of our sight. Our brains want/need to focus. That would be my answer to your question "What is the affordance of invisibility?".

The example of Google - if that really is a delete contact button, I don't use that app - I would agree is bad design, because its effort to find it outweights the benefits of having it hidden (partly because its placement is not apparently logical and that makes it extra hard to find).

In the first example in the article (github) however, I would tend to think that that specific solution is OK. The author of the article forgot to explain what that button does. A quick look at github, a rollover and a click (three actions) shows me that its function is it edits the description of the repository. How often do you edit the description of a repository? Not that often. Probably very rarely. And the more you use github, the smaller its usage gets proportionally to the rest of the app. The day you need it, you'll find it relatively quickly. Because you've experienced this practice for a while in other sites, and even more so because you've seen github act like that every now and then. Your brain is able to predict that if you don't see it, it might very well be rollover-only. The first logical place you try is the within the repository dashboard, over the description of the repository. Not too hard. I think in this case the benefits of every time I read that page not having that element there and not having to neutralize it myself with my brain by ignoring it vastly outshine the effort of looking for it when I rarely need it. It's a good deal. [1]

I would love to understand a little more about why this concept didn't work out for you.

edit: typos, formatting and deleted some unneeded parts

--

[1] The github element in the case of a touch interface is not great, I would agree, because it's harder to predict that by touching the white area of the description the button will show up. But it works (as in: you can still access it). And you have to cut interface designers some slack (or instead give us the strength we need): we're still trying to figure out what to do exactly with the current mess of having two very different types of clients (mouse and touch) accessing our web interfaces. After we figure out if we should unify, we need to figure out how. Killing rollover interactions might be a necessary casualty in that road (but that would make part of me sad, there are wonderful usages of rollover, see for example the custom sliders in here: http://worrydream.com/LadderOfAbstraction/), either way I'd love to understand a little more, and I assumed that in this discussion we're focusing on rollover, not touch.

The boycott should continue until they either take - or announce their plan of - action. Until they do, this PR talk is nothing more than that.

Disclaimer: I use Ruby and have no experience with Node.js.

(edit: improved text)

Language preference aside, the fact that no language has good support in the browser, the server and stand-alone totally baffles me.

I do wonder about this. I don't think the challenge of the task is the only answer. I think - guess - the rest of the answer might be that in practice, most developers focus on one of those, maybe two (most probably server and browser), rarely the three of them. I know first hand that some do work on the three, but they must be rare, seeing the interest in this. Maybe the momentum of the app stores bringing web devs to work on apps could gradually make people more aware of the benefits of having a universal language. Don't get me wrong, I enjoy the variety of languages, but I would be very happy to be able to focus and become proficient at one only language, even if that means giving up on some language specific advantages.

Ironically (given of the context of the comment), javascript might be what comes closest today.

Sounds faster than the Java I know.

- The VMKit project is an implementation of a Java Virtual Machine (Java VM or JVM) that uses LLVM for static and just-in-time compilation.

Am I reading this right? A faster Java that doesn't require a virtual machine? Does this mean faster Java, Scala, Clojure, or even Ruby, and deployed anywhere that LLVM can build for (which means pretty much everywhere)? Sounds too good to be true.

- LanguageKit is a framework for implementing dynamic languages sharing an object model with Objective-C.

- Eero is a fully header-and-binary-compatible dialect of Objective-C 2.0

Has anyone tried Eero? It looks interesting (and seems to be compatible with Objective-C code): http://eerolanguage.org/from-objective-c-to-eero. One thing I didn't get from the documentation is does Eero still require header files?

Could you explain that?

This strikes me as an odd "next step". I don't code in Haskell or clojure, but I've been eyeing both and the impression I got is that Haskell is harder to grasp but more powerful once fully grasped (and nearly as portable as C++). Sort of a superset of lisp. It seems that the next logical step after a couple of months of Haskell is more Haskell. It evidently worked out great for him, but I'd have liked to know why he switched to clojure.

No shit. I'm talking about Objective-C. If more developers could use it and more often, we'd have better libraries, better developers, a better community. Look at the momentum that C++ has despite its flaws.

If you doubt that ObjC developers would be interested in using ObjC but don't because using it on other platforms is too exotic, check this thread: http://news.ycombinator.com/item?id=3205372

It is not unusual to only have one type of build system[1] supported per industry

So what? Doing things because it's the usual thing to do is not Apple's way of doing things and it's worked for them. That's also why I'm surprised with this.

Viruses that kill quickly and efficiently do not spread as well as those that cause some disease but allow their host to continue functioning more or less normally (all the while exposing many more to the virus).

While this perspective is sound and less alarming than the source, viruses like influenza can still spread relatively far, can't they? They are believed to be contagious one or two days before the onset of symptoms [1], leaving a quite big window open for contagion.

[1] When is a person with influenza contagious? A person is most likely to pass on the virus during the period beginning one to two days before the onset of symptoms and ending four to five days after the onset. http://www.vaccineinformation.org/flu/qandadis.asp