Ok-Cancel versus Cancel-Ok - <AUTHOR> https://www.factorio.com/blog/post/fff-246 <comment><USER3> This has been a debate for as long as I've been a UX designer (mid '90s), and probably much longer.

Ultimately, the answer about this UX style is very much the same as a question about writing style—there's no objectively right answer, but you have to be consistent.

For example, you can pick up any number of style books from Strunk & White to the Chicago Manual of Style and get different "right" answers about writing style, but any editor will tell you the ultimate solution is to be internally consistent.

The arguments for each approach have merit. "OK on the left" designers will argue that because we read from left to right, the positive response should be first. "OK on the right" designers will say that the positive response carries the user forward, and because we read from left to right, forward progress should be on the right.

My personal feeling is that there's another argument for OK on the right, which is that the majority of users are right-handed, so the default choice will be closer to their dominant hand if it's placed on the right.

Then again, I may be looking for evidence to support my preference, which probably arose from the fact that I began designing on the Mac, so I was conditioned to Apple's "OK on the right" standard at an early age, and I've simply conflated "familiar" with "correct."

So the answer from this veteran UX designer would be: Use whichever placement your users are going to be the most familiar with, but whichever you choose, be 100% consistent with the choice you make.

<comment><USER4> Back when I used to build model aircraft dioramas, a veteran told me "When you arrange vehicles in a diorama setting, always have them facing towards the left side of the board for maximum impact.".

His reasoning was that most people's eyes move left to right when examining something - which mimics their eye movement when reading text (at least in Western societies. In R-L countries I guess the opposite would be true).

He said that by position the nose/cockpit of the aircraft on the left side, people's eyes would always go to where the 'little humans' would sit first, then move away towards the right. Similarly if you had scale model humans in a diorama setting - place them on the left hand side.

Placing the vehicles going against their eye movement would also make their attention 'catch' and stop at details of the object 'moving' in the opposite way (something about how people who drive cars are just more instinctually aware of something that is moving against their direction of travel). Whereas if they had to scan in the same direction the vehicle was moving, their attention would just slip past interesting points.

I've used those lessons in most of my UX design nowadays. Placing buttons and important items towards the right of a page, with lesser items further right. The only exception is if it is a destructive action call (deleting a record etc.), then I usually place the button all the way to the right so it isn't in visual way and too tempting.

<comment><USER5> Toy cars in shops have the cars and trucks all facing right in the packaging. Maybe they've done some ab-testing to get this way. Maybe not.

Maybe putting his airplanes facing left made your veteran's models pop because they were inconsistent with other models.

Anyway, if you want to make people read the options on buttons, randomize the order each time the popup appears but always destructive buttons like "delete" red colours.

<comment><USER6> Please don't randomise the location of UI components. I don't want to have to find the button I want. Your users will thank you.

<comment><USER7> Agreed, but I would still do it on a small traffic/user to see its impact. This kind of data is invaluable.

</comment></comment></comment></comment></comment><comment><USER8> HN folks will appreciate the entire Factorio blog. They are super open about the design of their game and it's full of micro-postmortems.

[https://www.factorio.com/blog/](https://www.factorio.com/blog/)

Also, if you're reading this, you are in a demographic that is likely to absolutely love Factorio. Go buy it, it's 20 eur/usd, you won't regret it.

Some call it "Programming: The Game".

<comment><USER9> > Some call it "Programming: The Game".

This is actually why I _haven 't_ bought it (yet). When I have the urge to program something, I think I'd rather put that towards building something real than playing Factorio.

<comment><USER10> I love factorio because it's the most like programming _without actually being programming_. Opus Magnum is a game in a similar vein that came highly recommended, but I never got _that_ into because it _is_ actually programming: there's an instruction set that you program visually. Factorio, on the other hand, is closer to an RTS. Except whenever you find yourself doing something tedious, you can just put in a little more work to automate it and never have to do it again. It's the automation aspect of programming, but no actual programming.

<comment><USER11> This. My mind was blown when I realised that the initially hard to make grabber arm could be just put in a factory and suddenly I'd have an endless supply of grabber arms forever.

</comment></comment></comment></comment><comment><USER12> Technically, they're both wrong. Button labels should be verbs. The Cancel - Open example from OS X is the right way to do a dialog box.

<comment><USER13> Not really, Ok can be a verb. You can "Ok" a change.

<comment><USER14> "Ok" for a change (that's described in the body of the dialog's text) is... okay, I suppose.

But it's _better_ to mirror the action verb for your confirmation button, because users don't necessarily _read_ the text you present them with. So, instead of this:

        Delete xyz.jpg?
        </comment></comment></comment><comment></comment><comment></comment><comment></comment><comment>--
        The file 'xyz.jpg' will be
        permanently deleted.
        </comment><comment></comment><comment></comment><comment></comment><comment>--
                 [ OK ] [ Cancel ]

You have:

        Delete xyz.jpg?
        </comment><comment></comment><comment></comment><comment></comment><comment>--
        The file 'xyz.jpg' will be
        permanently deleted.
        </comment><comment></comment><comment></comment><comment></comment><comment>--
             [ Delete ] [ Cancel ]

And you get one more chance for the user to see what action they're about to perform.

There's very good, detailed guidance on this in the Windows design guidelines (the design-specific aspects are a bit dated since everything there refers to Vista/7-era UI elements, but their guidance on text and dialog styles is still applicable):

Text: [https://msdn.microsoft.com/en- us/library/windows/desktop/dn7...](https://msdn.microsoft.com/en- us/library/windows/desktop/dn742476\(v=vs.85\).aspx)

Dialog Boxes: [https://msdn.microsoft.com/en- us/library/windows/desktop/dn7...](https://msdn.microsoft.com/en- us/library/windows/desktop/dn742499\(v=vs.85\).aspx)

<comment><USER15> Actually "mirror the action verb" surprises/confuses me even more than "OK" "Cancel", since the latter are standard and almost expected, whereas anything other than a positive/negative response feels unexpected. It's like the real- life equivalent of asking someone a yes/no question --- you're expecting a yes/no answer. In fact, I'd say this is even clearer, putting the question at the end and immediately following it with the two choices:

        The file 'xyz.jpg' will be
        permanently deleted.
        </comment></comment><comment></comment><comment></comment><comment></comment><comment>--
        Delete xyz.jpg?
        </comment><comment></comment><comment></comment><comment></comment><comment>--
                    [ Yes ] [ No ]

...and this also coincidentally gives a reason for the order of OK/Cancel --- affirmation on the left, denial on the right.

<comment><USER16> Please force the reader to directly click an action verb. It is much easier to skip over text (even text that comes immediately before) misinterpret the dialog, and click the wrong button when using generic button labels "yes" and "no".

And more generally, before disregarding industry best practices and findings from research literature and implementing something based on ad-hoc personal hunches, make sure you run some experiments on real people.

<comment><USER15> _industry best practices and findings from research literature_

That's the cop-out answer I get whenever I ask about unnecessary and infuriating UI changes. It has only given rise to increasingly dumbed-down, stupifying interfaces.

<comment><USER16> Huh? It is a "cop out answer" to suggest reading the research literature as a general practice? It is an "unnecessary and infuriating UI change" to roughly follow UI guidelines written down by experts with decades of experience?

I am recommending that instead of just making something up based on the developer's speculation and personal preference (which in your particular example happens to be terrible, as you would discover if you actually tested it in a real-world setting), it is a better idea as a general rule to go read actual user studies about what works and why, or if you are too lazy to do that go find some interface guidelines written by someone who did large-scale user studies and spent decades honing their interfaces in response to user feedback and copy it.

If you insist on rejecting those findings and past experience with a novel implementation, then I am recommending running your own mini studies (ideally something semi-formal, but at least test the two versions on a couple buddies at a coffee shop), to make sure you don't shoot your foot off. To do anything less is in my opinion lazy and irresponsible.

Why do you think that will lead to "stupefying interfaces"?

You think that doing at least a tiny bit of user research before blindly rushing ahead based on personal preferences renders people unable to think or feel?

Or maybe you have a non-standard definition of "stupefy"? To be honest I don't understand what you are trying to say.

<comment><USER15> _which in your particular example happens to be terrible, as you would discover if you actually tested it in a real-world setting_

My points all come from real-world experience, both as a user and developer. These unwanted UI changes irritate me enough to complain about them, but apparently my opinion doesn't count at all, because these so-called "experts" will only parrot their vague "studies show that X, therefore you are wrong"? These "user studies" naturally bias towards the worst of the worst. In fact, you are displaying exactly the sort of dismissive holier-than-thou attitude that I've been on the receiving end of, multiple times, and I can personally tell you that it _really fucking pisses me off_.

Think about it: if I'm the user of your software, and you change it so that it breaks my workflow, I am not going to be happy regardless of whatever justification you provide.

Having been on the receiving end of that, I've learned not to do it to my users, because I know how it feels.

<comment><USER16> I honestly have no idea what you are going on about. Nobody else is talking about "changes", workflow-breaking or otherwise.

You said "In fact, I'd say this is even clearer, putting the question at the end and immediately following it with the two choices:"

Did you ever test this explicitly vs. the recommended alternative of using verbs for labels? (Ideally by doing a user study, but heck, I'll take anything...)

I claim that this has been empirically tested and found to be inferior (i.e. result in higher error rate) in a variety of studies, both in published research and internal to various large companies which then got baked into their design guidelines. This was a subject of active research in the 1970s–1990s (and perhaps before).

You can find reasonably good advice about the subject in any number of introductory interface design textbooks, etc.

In this particular case, where user data is being irrevocably deleted, errors are especially harmful.

Edit: Maybe the word "terrible" in my previous comment was unfair. Sorry to be inflammatory.

</comment></comment></comment></comment></comment></comment><comment><USER17> It's not just the _order_ but the _placement_ , the _titling_ , and ultimately the whole message being presented.

Windows managed to do this as backwardly as possible (no pun intended). Switching their button order vs. the Mac might not have mattered if Windows put the first button in the bottom _left_ corner for predictability. Instead, they right-justified an entire group of left-ordered buttons so you have no way of knowing if the corner button will be the main action. Then they tended to use nondescript button titles, made worse by APIs that make it easier to pop up yes/no questions than Action1/Action2 (i.e. custom titles) so apps lazily trend toward nondescript. And _then_ the OS had relatively tiny fonts without formatting that made it hard to understand at a glance what a message is even asking, requiring careful reading to proceed.

A _good_ UI is not a very simple thing, there are lots of details to be considered.

</comment><comment><USER18> On macOS I have turned on the setting that lets one tab through all controls (System Preferences → Keyboard → Shortcuts → All controls).

When a "Cancel OK" dialog appears, "OK" is the default choice (in blue) but Cancel is the highlighted one[1], presumably because it's the first option. This is incredibly convenient because ↵ will activate "OK", while pressing the space bar will activate "Cancel". One gets used fast to pressing a single key to act on a dialog, instead of having to tab through controls.

[1]: [https://i.imgur.com/zsX66tX.png](https://i.imgur.com/zsX66tX.png)

<comment><USER19> Wow, you have to manually activate such an option? On windows it's default.

One of the things i love about windows is that it's always been designed for keyboard only use, not just bolted on as an afterthought. Every dialog, widget, application and feature can be used with only the keyboard and it's fast, easy and predictable how to. Unfortunately since windows 8 there's been some regressions in this area with the new metro interface. Defaulting the underlined hotkey to off (since windows xp), was also a big mistake imo.

<comment><USER20> Keyboard support on the Mac is _terrible_. It's probably the biggest flaw of the OS, imo. You wouldn't believe some of the ridiculousness - for example, the page up/down, home/end keys are application-specific in their behaviour. Moreover, they sometimes move the view, _but not the cursor_ \- an insane behaviour. I regularly find myself moving to the top of a document using the keyboard, then remembering I'm wasting my time and reaching over for the mouse, one click, and back to the keyboard...

<comment><USER21> > Moreover, they sometimes move the view, but not the cursor - an insane > behaviour.

It's an incredibly useful behaviour.

I can't tell you how many times I've had my cursor ready to type a method name, realized I didn't recall the precise wording of the method or the order or type of its arguments, and paged my way up to where the method was defined in the same file...then _not_ had to labouriously search my way back to where I was and click in the right spot to type, but just start typing as soon as I had the information. Bam, it types it in the right spot and jumps the view back to it for me.

</comment></comment></comment></comment><comment><USER22> I briefly managed a team where the two senior developers were in the middle of a style war. Half the team was K&R the other OTBS. And half the UI was Ok- Cancel and the other half Cancel-Ok.

Years ago, we had a critical for a "company saving trade show demo" setup on an early version of Windows NT. There was a server fault and when we brought it back up there was a glitch. No matter what we did the system kept presenting us with a modal warning that proceeding would probably destroy the data on the hard drive. The choices where Ok and Continue. After several calls to MS we finally called our partners and GE was able to back channel us to the developer who wrote the modal who told us "Continue" was the safe option. At least he admitted it wasn't the best way of presenting "do it" or "skip this step" options.

Personally, I'm firmly in the Cancel —- "verb the thing" camp these days.

</comment><comment><USER23> All of these are wrong, because they're answering the wrong question. Stop second-guessing the user!

Get rid of all these buttons, but provide a mechanism to UNDO the change. Linear undo plus the option to reinstate "factory default" settings is probably optimal for most applications.

Would you tolerate a text editor that asked you to confirm each letter you typed?

<comment><USER24> Undo support can 5x the cost of a feature and in some cases is impossible (instructing some other entity to perform an action). It's not feasible in all scenarios.

<comment><USER25> It depends how you architect. Generally yes. Check out the Elm architecture (and Redux by extension) to see situations where undo is essentially free.

<comment><USER26> Anything where your app state is modelled as a series of actions over immutable data, undo and replay will be essentially free to implement :)

<comment><USER27> destructive updates to your universe, or actions with side effects (anything regarding io) might not be recovered by a simple state management. delete my account, charge my credit card, add a friend, delete a friend...

<comment><USER26> But that is precisely how undo is currently implemented most of the time. Its a series of actions where you know how to undo the side-effects, or you know it was a destructive update and you just skip the undo of that step.

Where I have issues with that is it usually feels like an afterthought rather than a first-class feature.

If you instead model your application after an event log then your current state is just a fold over these events. You have the same list of actions you previously had to manage undo, but now its positioned at the very center of the architecture.

And then you start seeing emergent features of that design:

\- you can time travel the UI's state, which is probably the best debugging tool you can have for UIs.

\- you can replay the event log over fixed application code, which greatly decrease iteration times.

\- it moves logic outside of the UI components, making the app easier to unit test.

\- you're storing a sequence of intents rather than results; its effectively free to audit such a design, its convenient to report the last X actions performed with a bug report and more precise than asking the user what they were doing.

The list goes on and on. I believe most of the complexity in applications is generated from the fact there is very little synergy between the different features of these applications. If everything requires a different abstraction and set of indirections, then you're just accreting complexity over time.

If you have a design where features can emerge from it, its usually a safe-bet to say you're on to something :)

</comment></comment></comment></comment></comment></comment><comment><USER28> Interestingly, Apple's Human Interface Guidelines from the 80's do not say the order must be Cancel—OK.

They say:

 _"In general, dialog boxes should be laid out with the most important information and controls at the top left, working down to the less important information, ending with the default button—the button most likely to be clicked—at the lower right"_

So, there's "in general", and "most likely to be clicked".

The first leaves wiggle room, and the latter opens the door for changing the order. They even almost give an example: an alert "Are you sure you want to erase all changes to your document?" with buttons "Erase" and "Don't Erase", in that order, with "Don't Erase" being the default button.

I don't remember ever seeing a dialog on a Mac in those years that had OK—Cancel, though (there were a few in the 90's from bad ports)

</comment><comment><USER29> There was a widely used program on Windows back in the 95 days that on the nag dialog asking free users to get the paid version would random switch between the two orders. The idea was to keep people from unconsciously clicking through that dialog.

I think this was WinZip, but am not certain.

<comment><USER30> It's an effective dark pattern. Many websites practice similar trickery.

<comment><USER31> I wouldn't call it a dark pattern: there's no trickery or deception; nothing bad happens if you pressed the wrong button. It's called a "nag screen", and in many cases it's the only difference between a trial version and a paid one.

Here's an example from Total Commander: [https://www.dedoimedo.com/images/computers_new_2/windows- coo...](https://www.dedoimedo.com/images/computers_new_2/windows-cool-apps-tc- nag.jpg)

(the number to press changes randomly between launches)

<comment><USER30> It's an attempt to trick the user into clicking the wrong button. Maybe not dark, since all that happens is it annoyingly opens an website, but nonetheless, it is not pleasant or user friendly to intentionally deceive others into doing something they wish to avoid. I believe that practices that are labeled the dark patterns on websites often have no more impact than that.

I'd call it 'user hostile'.

<comment><USER31> No, it's a attempt to intentionally slow down user. I don't remember nag screens that open websites: it either tells you that you press the wrong button and re-randomizes the button order or quits the program. There are also versions that just have a timer that enable "Continue" button after a few seconds (e.g. [https://kinzuakid.files.wordpress.com/2009/05/gsak-nag- scree...](https://kinzuakid.files.wordpress.com/2009/05/gsak-nag-screen.jpg)). It's very different from websites that trick you into clicking a button that leads you somewhere. It's a _nag_ screen in a demo version that you can get rid of by purchasing the program. It intentionally nags/annoys users, but very far from dark or gray patterns. In fact, many of them only appear if you violate the license by using the program after the allowed period; being slightly less user friendly but still allowing users to use the program.

<comment><USER30> I do recall nag screens that open websites, so that's what I am referring to. I believe Winzip did this, as did other 2000 era software. It seems to me that this happens in many mobile applications in modern times, though I don't know as I don't use many. Since many screens in mobile applications are drawn from the Internet and serve the same purpose as a website, the distinction is not significant.

Opening parts of the application that I don't intend to open in an attempt to force me to look at them is disorienting, distracting from work, and gives rise to emotions that I do not wish to experience.

As far as your conclusions about this not being user hostile, or a gray or dark pattern, I disagree. We must be operating from different definitions of user hostility. I don't wish to participate in psychological warfare and regarding my use of a program. If they wish to cut off or restrict usage of it, they should simply do so.

As far as things like timers or other shareware style restrictions, they seems legitimate to me, though obsolete. It strikes me as a different topic.

</comment></comment></comment></comment></comment></comment><comment><USER32> One thing bugs me about the GNOME way of doing things. OK is on the right, cancel is on the left, great. Consistent and easy to get used to.

But...with client-side-decorations, these dialog buttons are often present _instead_ of the window buttons (i.e. close/minimise/maximise). But the window buttons are on the _right_!

So you want to close a normal window with window buttons? Top right. You want to cancel a dialog box that uses CSD? Top _left_.

This confuses my muscle memory to no end, as I have to check if a window is a dialog box or not before I can move my mouse to close it. And it's not like they'll eventually make every window a dialog box - accidentally opening gnome-terminal will always be a normal window to be closed with the close button and not a dialog button.

I think the best solution is to switch the Window buttons to the left like Ubuntu used to do.

</comment><comment><USER33> Countless times i've been victim of the "do you want to save?" dialog where the replies were |Yes|No|Cancel|. In some cases the brain knows it made a mistake, and whatever dialog comes, the reply should be the negative one. And with those options, the subconscious clicked No (the most destructive operation) before I knew what was happening. To me, the buttons should read |Save|Discard|Go back| in whatever order the creator wants. I think that even the dialog could just skip the text, with those button labels it isn't needed at all.

<comment><USER34> Factorio's Save implementation is one of the worst I've ever seen.

If you start a completely new game, the default name for a save game is the previous game you were playing. This means that you can very easily overwrite hundreds of hours of gametime by dabbling in multiplayer or a test map.

I reported this but it got closed by some jerk moderator as "working as intended" \- looks like it got forgotten: [https://forums.factorio.com/viewtopic.php?f=23&t=46646](https://forums.factorio.com/viewtopic.php?f=23&t=46646)

It's still the behavior in the game.

</comment></comment><comment><USER35> Years ago I read an article [0] that was championing Cancel-Ok based on the fact that most of the world reads from left to right and thus the eyes move from left to right. If you use Ok-Cancel, user's eyes have to essentially go back to the positive action, which is the one that they do more often.

[0] [http://uxmovement.com/buttons/why-ok-buttons-in-dialog- boxes...](http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work- best-on-the-right/)

<comment><USER36> I wonder if they are really sure about that.

What do you think, no or yes?

<comment><USER35> Well, it convinced me at that time, so now I force all our designers to structure it also as Cancel-Ok. On the surface it makes sense to me, but that doesn't mean it's correct.

So I go with Cancel-Ok, but holding this conviction very loosely.

<comment><USER36> This is one of those things where there is no wrong or right answer. We are just trying against all odds to find _something_ that will help users feel comfortable and make the right choice.

My philosophy used to be to follow the native platform convention, so on Mac it's Cancel-OK, on Windows or Linux it's OK-Cancel. Seems simple, do what people are used to.

But what about a web app that someone uses on Mac at work and Windows at home, or vice versa? Do they expect the app to work the same wherever they use it, or do they expect it to follow the different native platform conventions?

My mind is spinning.

<comment><USER37> > Linux it's OK-Cancel.

KDE yes, but GNOME and most GTK+ desktops and apps are definitely Cancel/OK.

Google used to be pretty mixed, but Android and the Material re-designed stuffs seems to be pretty much Cancel/OK too.

<comment><USER38> As i show in another reply below, it is only GNOME/GTK that does Cancel/OK, while every other environment and toolkit does OK/Cancel - this includes KDE, Tk, Motif, FLTK and even some classic X11 apps like `bitmap` use OK/Cancel. This is also the case with console-based UIs, like dialog, picotui and free vision which all use OK/Cancel. So GNOME/GTK is really the odd one out going against what everyone else is doing. It is also interesting to note that this was changed in GTK2 days since GTK1 does also use OK/Cancel: [http://pike.lysator.liu.se/generated/manual/images/predef.GT...](http://pike.lysator.liu.se/generated/manual/images/predef.GTK1.FontSelectionDialog.1.png)

<comment><USER37> I'm not disagreeing, but on the Ubuntu MATE computer I'm using now, for graphical apps at least, I have only have apps using GTK+ — including partial users like Firefox —, Qt and wxWidgets (plus mpv, which doesn't seem to have any dialogs anyway). Qt and wxWidgets adapt to GTK+ conventions when used with GTK, or use parts of GTK+, like open/save dialogs, so everything, or nearly so, that I use is Cancel/OK.

I think GNOME started intentionally copying MacOS starting with the GTK+ 2 days.

Out of curiosity, I just installed Blender, which uses its own custom toolkit. The only dialogs I could find were open and save, and it has the open/save actions on _top_ and cancel _below_. (That's actually what unstyled(?) Qt apps' open/save dialogs do too, as I've just seen in KeepassXC installed as a Snap.) That's one way to not take sides here ;-)

<comment><USER38> AFAIK in Qt you can "tag" the OK/Cancel buttons and the theme can provide a hint to swap them around, however the default seems to be OK/Cancel and KDE uses that going back to KDE1. I've also heard (but not confirmed since i do not have it) that if you use GNOME and run a Qt app, Qt will automatically swap the buttons - if that is the case then it might also do it with other common GTK+-based DEs.

About the vertical orientation, actually i've noticed that not only in Blender but in other programs and toolkits too. In the latter toolkits, it most likely comes from Win9x/2K/XP which used this vertical layout (i think Vista rearranged the buttons to be horizontal).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER39> > But little I knew, that this is actually specific to windows, and on Linux > or macOS, the order is reversed...

Did anybody else pick this up? The person has only ever seen Windows. That's extremely limiting.

A later comment talks about how Microsoft designed things... one of the big differences between Mac and (DOS and early Windows) was that Mac developers tended to use the Apple tool kit and design guidelines, but the other platform devs tended to inventvtheir own and go their own way — being deliberately different.

I taught computing in the early 1990s around the transition from DOS to Windows 3.1 and on a Mac if you learned to print in one app you had it right for all others. With DOS each app was a completely different set of key presses (looking at WordPerfect and Lotus 123). Windows standardised this but it took a while for devs to catch on that consistency with other apps is good practice

<comment> rkuykendall-com > Did anybody else pick this up? The person has only ever seen Windows. That's > extremely limiting.

The original Factorio team ( once they grew to 3 ) developed 100% on Windows, Mac, and Linux respectively. So Twinsen may have very little experience outside of windows, that probably helps him develop an authentic Windows experience, while the Mac and Linux developers do the same, and the result is a great cross platform game.

Disclaimer: My in-game hours for Factorio probably qualify me for Stockholm syndrome, so lots of bias here.

</comment></comment><comment><AUTHOR> > Make it so much different and Factorio specific, that the way it is done in > your specific system will not interfere with your muscle memory

I think this is a really thoughtful way to deal with the problem of x-platform UI that isn't using system chrome/dialogues. Don't get in the user's way, and let them develop muscle memory specific for the game.

<comment><USER40> Can you imagine a first person shooter game with dialog boxes popping up all the time? Shoot now? Shoot-Don't Shoot. Light switches with a dialog box? Light switch: on-off slider. Cancel-Reset-Apply Web sites that throw up overlays over the content to ask some inane question? oh, wait.

</comment></comment><comment><USER41> This explains why they're swapped for the print dialog in Chrome between Linux and Windows.

Often I select a word intending to search it, hit print instead and then hit the wrong button trying to cancel it. This is why I have pieces of paper with one word printed on them.

</comment><comment><USER42> I love this sentence buried at the end I don't think anyone has commented on yet:

"We plan that almost every widget in this GUI (and the of the game) will have tooltips briefly explaining what everything does, since for example not even us developers know what Enemy base Richness actually does any more."

Such an honest statement with absolutely no followup. Love it.

</comment><comment><USER43> I ran into this during in my old days of UI development using Java Swing. I eventually came across MiG Layout ([http://www.migcalendar.com/miglayout/cheatsheet.html](http://www.migcalendar.com/miglayout/cheatsheet.html)) which had a steep learning curve, but was extremely powerful.

In particular, you could give components a tag attribute, and it'd do platform-specific component reordering based on the tags. It was pretty sweet!

</comment><comment><USER44> > _The solution we are now experimenting it sounds like a bad idea: "Make it > so much different and Factorio specific, that the way it is done in your > specific system will not interfere with your muscle memory"._

I actually kind of like the solution they found, but I'd still argue that this way of reasoning really _is_ a bad idea.

If you remember your Kant - always act so that everyone could do what you do - this would be horrible.

UI is all about consistecy and while it's nice they don't want to interfere with the consistency of the rest of the UI, if every designer would use that excuse, we wouldn't have any consistency at all.

</comment><comment><USER45> I vote for Ok on the left (even though I have used macs for years) because Ok is the "normal," typical action. "Cancel" is only done when you've basically made a mistake by opening the dialog box. Since we read from left to right, someone working quickly will only have to read the first one to do the action without breaking their flow. If you are hitting cancel, your flow was already broken when you opened the dialog box.

<comment><USER46> I vote for Ok on the left because Cancel should be easiest to find without looking and thinking. When I decide I don't want to change anything this window is for I just click the lower-rightmost button unconsciously, faster than I can read it, e.g. the way you slap yourself when you feel like a mosquito might be there biting you. So, when the button there is not Cancel this can be destructive.

</comment></comment><comment><USER47> I always preferred, "Do <the thing>" or "Don't do <the thing>". Be explicit in what the buttons mean.

<comment> dylan-m Yep. That's one of the reasons I have always really appreciated GNOME: they're steadfast about buttons that do what they say, and it makes everything so much nicer to deal with for me. Part of this is GTK does a good job avoiding situations where stock OK / Cancel buttons are an easy way out. I think a reason for the vast number of them in other places is developers are lazy gits and lots of UI frameworks make it effortless (like, a single function that blocks your thread effortless) to create really lame question dialogs with ready-made generic labels.

<comment><USER48> GTK gets bad points for me because it forces me to use their file choosers, no choice to avoid that then attempt some runtime patching the applications.11

</comment></comment></comment><comment><USER49> You want to know bad design of a cancel button?

The lyft app when you want to cancel a ride has a "cancel" button that cancels the ride instead of cancelling the cancel.

Accidentally cancelled a ride one time in the middle of it when I fat fingered the first button and then stabbed at "cancel" thinking it meant "abort" and not "ok, continue"...

<comment><AUTHOR> Genuinely curious, what's a better way of doing this particular flow:

user taps "cancel" dialogue asks "Are you sure" and presents options: "cancel" and... "cancel"??

What should the options/dialogue be?

<comment><USER19> One of the options should be "Continue your ride" or "Return to your ride". The second one should be "Cancel ride".

Or you use the default back button of your OS (top left in ios/windows or hardkey on android) and only provide the "cancel ride" button to move forward.

</comment></comment></comment><comment><USER50> What if it wasn't a per org choice, but defined by a governing body? Similar to how countries implement which side of the road to drive on etc. Then each new startup/product team won't have to have the existential crisis invoking, bikeshedding conversations about this very topic.

</comment><comment><USER51> Well damn. Read an article about factorio at 5:30pm on Friday, there goes my whole weekend.

</comment><comment><USER52> In the very first example screenshot on that page, it would appear that the user is presented with _three_ different ways to cancel the action: clicking NO, clicking CANCEL, or clicking the close box. I would presume they effectively do the same thing? As far as I know this is typical of a Windows dialog box. I'm a Mac user: can someone tell me how this could possibly be considered good UI?

BTW, Cancel-OK dates from _both_ of OS X's parents: MacOS and NeXTSTEP.

</comment><comment><USER53> Going to the right seems natural to progress, but is that because English is left to right? If a language goes up to down, do their dialog boxes proceed downward?

<comment><USER54> Apple Human Interface Guidelines do indeed recommend the "OK" type buttons on the left for right-to-left texts (and put the menus on your mobile apps on the right instead of the left, etc). Computers do not generally use vertical text for localization, for example, Chinese and Japanese are left-to-right as far as the computer is concerned. (This doesn't apply _in all cases_ just to the way UIs are localized. You can still make text vertical, for example, see [https://www.w3.org/TR/css-writing-modes-3/](https://www.w3.org/TR/css- writing-modes-3/))

</comment></comment><comment><USER55> If you assume that people tend to consider all options before making a choice, putting the primary action on the right makes sense. If you put the primary action on the left, a user will see it first, but then read on to look at the other options. Once all options have been considered, the user has to go back to click the first option. If the primary action is last, the user can immediately click it once all options have been seen.

</comment><comment><USER56> We have a review software that has buttons "Wait"-"Approve" and then "Sign"-"decline". So on one screen the positive button is on the right but on the other it's on the left. I have declined tons of reviews just by clicking on the right button reflexively.

<comment><USER57> Is this intentional? Do they want you to be really sure?

<comment><USER56> I doubt it. There is no "are you sure?" on the decline button. So typically I decline something and wonder why two days later someone complains why have declined his review.

</comment></comment></comment><comment><USER58> As long as it is consistent with the OS.

Linux programs are especially bad in this. You never know what you'll get.

</comment><comment><USER59> The way I see this debate is very simple: some people in parts of the world drive on the left side of the road, and some people in other parts of the world drive on the right. I might argue there is only one "right" way to drive, but both are valid approaches.

</comment><comment><USER60> If it is matter of vote, I'd vote for Ok --> Cancel most of the time.

My justification for this is to avoid accidentally going for Ok when what you want is Cancel...but this happens to be biased against left-handed people!

<comment><USER61> OK then cancel makes sense because 'OK" is the first, and therefore default option

Cancel then OK makes sense as 'OK' is then in the bottom right corner, same place as the 'next' in a wizard GUI. But call it 'Continue' or something, whatever you're saying OK to.

<comment><USER62> I think that a lot of the thinking behind putting the action to the right is to have Cancel be sort of the default option (the keyboard'd still default to the action) as a way of avoiding user automatically doing actions they regret (and with the presumption that cancelling won't make them lose any work).

Of course, once they get used to that, it still becomes automatic

</comment></comment></comment><comment><USER63> As a UX designer, I think consistency is key. And if your user base is mostly on Windows, go the windows way. If they're mostly on OSX, go the Apple way...

</comment><comment><USER64> The most important aspect of this is keeping it consistent.

Speaking of which... Android messed this up royally where they just changed their minds and changed all dialogs to the other way with (if I remember correctly, which I probably am not) Android 4.0 Ice Cream Sandwich. Drove me insane trying to relearn muscle memory to ok/cancel.

Maybe they have documented their reasons for it? (couldn't find it)

</comment><comment><USER65> I only know one thing. When I use Venmo to charge my friends I often end up paying them instead. Right side primary. Right hand dominant.

</comment><comment><USER66> I'm not a UX person but I notice bank ATMs places OK (Action) button on the right, and Cancel on the left. Recently I encounter an ATM by a new bank which places the button the other way, and feel weird. So my guess is there is no right way or wrong way. Just the way we're used to.

</comment><comment><USER67> One of the masterpieces I've read on developer created UI. [https://blog.codinghorror.com/this-is-what-happens-when- you-...](https://blog.codinghorror.com/this-is-what-happens-when-you-let- developers-create-ui/)

</comment><comment><USER68> There was a lot of good work done by Apple in the days of classic Mac OS - <USER2> eg pages 103, 196-7, 201 and 206-7 from the Macintosh Human Interface Guidelines, available eg at [http://interface.free.fr/Archives/Apple_HIGuidelines.pdf](http://interface.free.fr/Archives/Apple_HIGuidelines.pdf)

Some of the reasons behind the suggestions (which are clearer when you view the associated pictures in the pdf):

"The Western reader's eye tends to move from the upper-left corner of the dialog box to the lower right. Put the initial impression that you want to convey in the upper-left area (like the alert icon), and place the buttons that a user clicks in the lower right. Following this guideline makes it easier for users to identify what's important in a dialog box."

"The button names in the save changes alert box correlate to the action users perform by pressing the button. The buttons read Save, Don't Save, and Cancel. Using these verbs reinforces the identity of each possible action to the user. In other words, the Don't Save label provides much more context for the user than the word No does."

"In order to prevent accidental clicks of the wrong button, you should always keep safe buttons apart from buttons that could cause data loss. Standardizing the location of buttons in a safe configuration provides an additional safeguard for the user. Place the Save button in the lower-right corner with the Cancel button to its left. Place the Don't Save button left-aligned with the message text. Make the Save button the default button, which means that it should be linked to the Return or Enter key. This way, the user is less likely to accidentally click the Don't Save button or activate it with a keystroke and cause irretrievable loss of data."

"Whenever possible, name a button with a verb that describes the action that it performs. Button names should be limited to one word whenever possible. You should never use more than three words for a button name."

One good justification for the Cancel->OK order is that it means the default button (usually the OK button, but also Save, Print etc) is always in the same position in the dialog -- far bottom right -- regardless of how many other buttons there are, and how wide they are. This gives consistency / familiarity / muscle memory.

It also lets you place "data loss" buttons well away, in the far bottom left, as "an additional safeguard for the user". On classic Mac OS, you always knew pressing a button towards the lower left corner, and set away from the other buttons, could spell trouble.

The problem with the Windows way of doing things is that the default button moves depending on the width and number of other buttons, and there is no "safe button place" and "unsafe button place".

</comment><comment><USER19> How about top to bottom? Like the windows copy file dialog where there is no obvious correct way forward or back: [http://i.stack.imgur.com/GeQG7.png](http://i.stack.imgur.com/GeQG7.png)

<comment><USER69> Cancel is pretty obvious to go back. I don't find this good at all, you really have to read what is going on. A simple replace/duplicate/skip would be better for me.

</comment></comment><comment><USER70> Like everything else, whatever benefits one or the other has is far outweighed by consistency with the host environment, if you can do it. But of course a game on multiple platforms has constraints that make this difficult.

</comment><comment><USER71> So why do Samsung android phones put the "back button" on the right contrary to the other android devices?

In latin and germanic languages, left means back, cancel, undo, bad whereas right means continue, progress, right!

<comment><USER72> Because early Android devices had the back button on the right. See for instance the first Android device ([https://en.wikipedia.org/wiki/HTC_Dream](https://en.wikipedia.org/wiki/HTC_Dream)): the button order was according to Wikipedia "Call", "Home", "Menu", "Back", "End Call".

The standard Android button placement later changed to have the back button on the left, but Samsung kept the old order, probably so that users who upgrade their phone within the Samsung Galaxy series don't have to relearn their muscle memory.

</comment></comment><comment><USER73> I think, for mobile design, it is relatively more straightforward to press the button on the right (because most people are right-handed), that's why `Cancel-Ok` design is getting more popular.

</comment><comment><USER38> > But little I knew, that this is actually specific to windows, and on Linux > or macOS, the order is reversed

Actually on Linux it depends on the toolkit and/or environment you are using and in this case it seems that GNOME/GTK is the odd one out. After doing some search, it looks like that every other toolkit and environment uses OK -> Cancel:

[http://ocsmag.com/wp-content/uploads/2015/02/plasma- krunner-...](http://ocsmag.com/wp-content/uploads/2015/02/plasma-krunner- modules.png) (KDE)

[https://docs.kde.org/trunk5/en/kdeaccessibility/kmouth/kmout...](https://docs.kde.org/trunk5/en/kdeaccessibility/kmouth/kmouthctts.png) (KDE)

[https://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kdial...](https://api.kde.org/4.x-api/kdelibs- apidocs/kdeui/html/kdialog.png) (KDE)

[https://www.sao.ru/hq/sts/linux/book/xbook_marshall/prompt.g...](https://www.sao.ru/hq/sts/linux/book/xbook_marshall/prompt.gif) (Motif)

[https://www.sao.ru/hq/sts/linux/book/xbook_marshall/dialog1....](https://www.sao.ru/hq/sts/linux/book/xbook_marshall/dialog1.gif) (Motif)

[http://northstar- www.dartmouth.edu/doc/idl/html_6.2/images/m...](http://northstar- www.dartmouth.edu/doc/idl/html_6.2/images/macro02.gif) (Motif)

[http://www.antillia.com/oz++/images/IconBar.png](http://www.antillia.com/oz++/images/IconBar.png) (Motif)

[https://tkdocs.com/images/idleprefs_l.png](https://tkdocs.com/images/idleprefs_l.png) (Tk)

[http://zetcode.com/img/gui/tkinter/colorchooser.png](http://zetcode.com/img/gui/tkinter/colorchooser.png) (Tk)

[http://www.fltk.org/doc-2.0/html/filechooser.gif](http://www.fltk.org/doc-2.0/html/filechooser.gif) (Fltk)

Even on TUIs/Console the order tends to be OK -> Cancel:

[http://linuxcommand.org/images/adventure_dialog- radiolist.pn...](http://linuxcommand.org/images/adventure_dialog- radiolist.png) (dialog)

[https://i.imgur.com/ruW7AQE.png](https://i.imgur.com/ruW7AQE.png) (Free Vision)

[https://raw.githubusercontent.com/pfalcon/picotui/master/pic...](https://raw.githubusercontent.com/pfalcon/picotui/master/picotui.png) (picotui)

Also FWIW in my own programs i am always going OK -> Cancel since it feels more natural.

<comment><USER74> IIRC KDE (or was it Gnome) changes the order depending on whether it's a RTL or LTR locale.

<comment><USER38> Apparenly Windows does that too [1] (or did at some point, i can't find any recent shot that showed a dialog box). It actually looks like it flips the entire window horizontally in RTL :-P.

[1] [http://www.geocities.ws/mowasel/tech_zone/images/dialog5.jpg](http://www.geocities.ws/mowasel/tech_zone/images/dialog5.jpg)

</comment></comment></comment><comment><USER75> Simple for me. OK on right, because it's like go forward. Left is like go backward. Everything else is just confusing to me. Your mileage might vary.

</comment><comment><USER76> I like OK Cancel because it implies that tab-enter on the last entry field is submit without breaking expected left-right right flow of tab index.

</comment><comment><USER77> I'd downvote this for the title if I could.

Better:

> Ok-Cancel versus Cancel-Ok: [added value of article]

E.g.: "A/B tested", or "a historical review", etc.

<comment><AUTHOR> I thought the HM guidelines required titles be as true to the article as possible. I'll keep your feedback in mind next time I submit a link! Thanks.

<comment><USER78> You are supposed to use the original title. You aren't supposed to editorialize.

There are some exceptions to the rule of using the original title. They are listed in the guidelines:

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><AUTHOR> That's that I thought! Thanks for the comment.

</comment></comment></comment></comment><comment><USER79> Just to remind us, millions of people live in societies that reading is right to left [https://en.wikipedia.org/wiki/Right-to- left](https://en.wikipedia.org/wiki/Right-to-left)

I think both ways are correct, and independent of what we chose, the most important is the application keep coherence and cohesion with itself and (when it is possible) with it's enviroment.

</comment><comment><USER80> Does it bother anyone else when the "k" is not capitalized in "Ok" on a button?

<comment><USER40> The cache size is currently 0k. Increase the cache size?

Ok-0k

<comment><USER40> Do you wish to Cancel?

Cancel-Cancel

</comment></comment></comment><comment><USER81> You could think of it as previous and next. They cannot be swapped.

<comment><USER82> For Mac/Linux, sure. But that's not what Windows users are used to, and therefore don't model as "previous/next".</comment></comment>


Mercurial Queues are like Git's index on steroids - <AUTHOR> http://stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/

<comment><USER2> Actually its the other way around. Git branches with rebase and amend for commits are like mercurial patch queues on steroids.

At Astrails we used mercurial for a couple of years with quite an elaborate workflow involving _shared_ patch queues which were in their own mercurial repository.

Once we switched to git I tried for a while to force similar workflow on git. I investigated stgit, quilt etc to try to use patch queues with it. Nothing quite worked so we kept just using the regular git with topic branches and once I learned all the 'magic' git stuff like "commit --amend" and "rebase -i" I realized I no longer needed patch queues. Actually the workflow become much more streamlined and easy to follow.

<comment><AUTHOR> "git rebase --interactive" can certainly be used instead of patch queues if you're careful not to mess with published changesets. Mercurial has the histedit extension[1] which does the same thing.

The one thing rebase -i and histedit can't really duplicate is _versioned_ patch queues. If you want to keep track of changes to patches over time then rewriting history won't help you.

Perhaps you have a big feature with a bunch of moving parts that you want to refine as you get feedback/code review. With versioned queues your colleagues can see what parts of your patches changed since the last time they reviewed them, instead of looking at the entire set of patches as a whole.

[1]: <http://mercurial.selenic.com/wiki/HisteditExtension>

</comment></comment><comment><USER3> I thought the closest thing in Git to Mercurial queues was Git stashes.

<comment><AUTHOR> Nope, that's probably the shelve extension: <http://mercurial.selenic.com/wiki/ShelveExtension></comment></comment>


Making open-source development work for businesses - <AUTHOR> Hi guys,
Wanted to discuss something that we've been working on.
Open-source software suffers from a tragedy of commons. Since the benefits are diffused and costs are concentrated, it does not receive the investment that's proportionate to the amount of value it generates for its users. Things really are in a bad shape.
Take your work scenario today. You start using an open source tool say, a cli based deployment library, only to find out that the library doesn't support config option while deploying nor can you customise it. Now, in order for you to customise it, you need to work on that library, submit a PR which might or might not get accepted depending on the activity in the project by their respective maintainers. All this, and now you have gotten far away from the actual problem that you were working on. Now, frustrated as you are, you switched to a paid library which does what you ask for but comes at a huge cost.
We come in at this point. You can get your problem sorted in the open source library at a fraction of the cost of the paid one and also save time at not having to think anything beyond your own business scenario.
Check out more details here: https://polyglot.network/about/
If you feel this might sound interesting to you, feel free to reach us out at email@example.com and let's discuss the open source stack that you need help in. <comment><USER2> Take away all the frills and you're just a contractor. The past two organizations I've worked at forked the open source libraries we modified. If upstream didn't want our changes, so be it. That said, we generally tried to communicate with the maintainers/community to better ensure the change was accepted.

What sets you apart from any other contractor?</comment>


Implementing SCRUM - story of a Seedcamp winner - <AUTHOR> http://blog.seedcamp.com/2009/02/its-all-about-education.html How our team switched to SCRUM and why we believe it is important to have a development methodology when you are a startup. <comment><USER2> I worked with Ken Schwaber while at my last startup. I'd be happy to offer insights, but not in a public forum.

It's also very interesting to see SCRUM being given credit for "quadrupled revenue in 2007" at PK: <http://bit.ly/RsRNm>

In reality, pretty much all of that revenue (~70% increase) was due to a single very, very big deal with HCA: <http://bit.ly/Rtq7i>

That particular deal was based on a project that I identified, prototyped, developed, installed, refined and then went on the road to sell.

I can categorically say that it had very little to do with SCRUM and much more to do with a tremendous (and very small!) team of three that I had the privilege of working with who helped in identifying a fallow market, building a great product, and marketing it well.

<comment><USER3> I'd like to hear more about your agile experiences, if you like. My email is in my profile.

<comment><USER4> Me too - I'm building a presentation on Agile Design (designers integrating into agile groups) and could use more research into other people's setups. My contact info:

<http://alabut.com/contact.html>

I've worked with scrum, agile and xp groups, and have been gathering feedback on real world pros and cons.

</comment></comment></comment><comment><USER5> I'm surprised that a startup would even consider following one of these processes. They are responses to the organizational constraints of corporate software development (and its symbiotic relationship with big-name consultants). A startup isn't, or shouldn't be, subject to those constraints in the first place. So a startup that feels the need for such a process seems likely to have more fundamental problems than a process can fix.

I don't mean to criticize anything that's genuinely working, and one can't tell much about a particular situation from a blog post. But all other things being equal, I'd say something is wrong.

Edit: I missed this from the original article and just read it in another comment:

 _The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers._

Is this a joke? This is not only ludicrous behavior for a startup, it's _the very opposite_ of the process this startup has supposedly adopted. I take back "one can't tell much about a particular situation from a blog post". This says a great deal.

</comment><comment><USER6> "You separate the business from the development. You need a product guy, interested in features that will move the product fwd. He is called the product owner. He keeps a file (an excel works best) - a product backlog - with all the features, called user stories. They are organized by priority. The development team is run by a project manager. His role is to move the top priority user stories from product backlog to the sprint backlog and break them in atomic tasks that are distributed to your developers."

"break them into atomic tasks": I didn't think this sort of hyper- specialization would work in a fast-paced environment. It seems to treat developers as just English-to-C++ translators.

My experience has been that specifying in great detail _HOW_ to do things (as SCRUM does for s/w development) doesn't work as well as specifying _WHAT_ to do and letting people figure out how to do it, but holding them accountable for results. The latter style will naturally result in the evolution of automated systems such as regressions, quantitative user feedback, beta progam etc to ensure that the work got done and quality is maintained.

One should have some structure and avoid reinventing the wheel, but I'm skeptical of detailed recipes like this.

<comment><AUTHOR> When all the developers are the founders your approach will work. If you have a different dev team it is very very difficult to make your team so dedicated as you are. I think we have such a team but still having a system to put all the user stories on the same page and see how the team is moving helps a lot. If you reduce Agile to hyper specialization you loose a lot. It helped us a lot by: \- defining what Done means \- setting goals so we can release something new every 2 weeks \- measuring our activity: what doesn't get measured doesn't get managed etc

And it is not about telling people how to do things. They decide how to do it, how long it takes etc... So I think you either got that wrong or I explained it badly!

<comment><USER6> What I meant is that the SCRUM inventors are telling _you_ in great detail how to run the technical side of a software business. Not that it's telling the developer how to implement something.

<comment><AUTHOR> Not true. They give some principles and you have to decide how to use them. The same with GTD: you can use a pen and paper or an iPhone. How you do it depends on you.

</comment></comment></comment></comment><comment><USER7> My experience with SCRUM is that is sort of works for large organizations, but it's not a magic bullet.

It's best use is as a conduit for the introduction of sane development practices like unit tests, systems tests, and continuous integration.

I remain very skeptical of SCRUM for small organizations.

</comment><comment><USER8> Well, I'm a solo developer, so I've only kept agile strategies at the edge of my radar, but they've certainly persuaded me to keep aware of the issues... for that hoped-for time when I need to be part of a team.

<comment><AUTHOR> True but it works even for small teams. Once you are more than 3 people in the team it makes a lot of sense to use Agile methodologies.

<comment><USER9> > it makes a lot of sense

No it doesn't without proof. Can you show me proof that the methodology works when compared to others? Stats, studies, etc. where are they?

</comment></comment></comment><comment><USER3> Great to hear a new Scrum convert and the difference it can make in a team! (startup or otherwise)

Couple of notes from an old Agile guy:

1) The Product Owner goes away with a startup. Everybody is representing the business. The P.O. idea was always an oversimplification anyway. In reality you have to adapt. (This is true of all of this)

2) You don't have to plan every task. Some teams do, some teams don't. Stories are hunks of business value that you can deliver inside a sprint. Tasks are what you do to make stories happen. If you can grab a story and deliver it, tested and approved, without decomposing your story into tasks? Good for you. I say go for it. But it's a team decision. Some folks are just more detail- oriented than I am. All I care about is getting the value to the customers.

3) It's a framework, not a methodology. Scrum is a PM framework around Agile principles. It doesn't tell you _how_ to do things, simply the process for keeping track of your team's to-do list and executing on that list. It's all goodness and wondefulness, sure. But it's not the end of world hunger. Just some nice rituals to keep the team on-track.

4) The most important part of Scrum, or of agile for that matter, is to adapt. It's okay to totally screw-up. What I want to see is a team that is constantly improving their ability to deliver value. Whatever you read in a book or see in a seminar, you have to own and adapt it for your use. I've found that many folks get the idea of "process is evil" and then start to use cookie-cutter processes for their agile teams. Ouch. All of those rituals like stand-ups, showcases, retros and such? They're there because _over time we believe that most software development teams will adapt to use some form of them_. So start with them for a few cycles, then change it up.

5) Because of all of this, there is no conflict between Agile principles and startups. In fact, every startup I've seen that was successful was in some fashion agile. Startups are about providing perceived value to the customer quickly. Agile is about providing value to the Product Owner quickly. Unless you screw it up, it's the same difference.

If you haven't looked into it, I'd give some agile concepts a look-see. Even when I sole-developing I use a backlog, sprint, "done", etc. Not because I'm a fan, but because it is just the best way of working.

<comment><AUTHOR> True: it is framework not a methodology.My mistake.

<comment><USER10> _It's okay to totally screw-up._

Coincidentally the two times I have seen SCRUM at work so far it was deployed precisely to serve as excuse for the constant screw-up. Neither of the companies seems to have improved over that year of colored post-it notes either. But the CTO and product managers since then have new buzzwords they can use to justify why they still miss milestone after milestone...

YMMV.

<comment><USER3> It's okay to screw up _if you're continuing to improve_. Sounds like these guys weren't.

I tell my PMs that I train that no, I do not want them to be the CSM. I want them to work strategically, to work on all of those organizational obstacles that get in the team's way. You can't change the world, but good agile teams are going to be constantly reminding the CTO and everybody else that certain constraints are killing team performance.

You can treat it like a fad if you want -- just throw new labels on old crap. But whether it's Scrum, Agile, or Bob's New Process, at the end of the day the teams _must_ communicate back to the organization frequently about what's screwed up. And the organization must listen. Or you can just keep throwing money and fads at problems you won't acknowledge. Reality is reality. The reason you end up with poor understanding at the CTO level is because _nobody has the balls to tell him what's really going on._ That conversation is the toughest part of adapting in a nutshell (pun not intended).

<comment><USER10> Well, I sure hope someone uses these processes as they are meant and as you describe. This was not aimed at you personally, I just have never witnessed it.

In fact the words "Agile", "XP" and "SCRUM" have pretty much turned into red flags for me. My immediate reflex whenever someone feels a need to mention those to me is to bill by the hour - because anything else would probably come back and haunt me iteratively ...

<comment><USER3> I'd be careful of overgeneralizing.

Even in true management fads, there's usually a grain of truth in there somewhere.

Just don't be the guy who never picks up any new skills because 1) people usually misapply them, or 2) you had a bad experience. Everything is a tool in your toolbox. Lots of tools means lots of options.

I've found that even with "heavy" process overhead, like CMM or CMMI, if you talk to the developers they're supposed to be practical and make sense. _It's the way people in companies apply these things that are usually at the heart of why they don't work._ At the end of the day, it all gets back to people.</comment></comment></comment></comment></comment></comment>


What are your most common reasons for rejecting candidates after a job interview - <AUTHOR>

I reckon a number of you have conducted interviews for your organizations. As someone in the job market with a strong professional/educational background (Bachelors and Masters from top schools, internships at top companies and entry level to mid management roles at top companies in the Valley), I am curious as to what the most common reasons are for why you ultimately don't advance candidates to the next stage of the interview process.
I have no problems getting interviews but  often don't get moved on to the second/final rounds. I know you must want some more information about my professional history to be able to give useful advice but I am unable to do so to protect my identity.
However, I would appreciate if you could share some of the most common reasons why you typically reject interviewees. Thanks. <comment><USER2> I failed people that didn't pass the technical part of the interview.

Nowadays, people seem to care less about this technical aspect and more about whether they like you (but perhaps it has always been this way). They also seem to be stuck on very specific ways of doing things (to the point that their reasons for not hiring you may seem arbitrary and stupid), and anything that's even slightly off from this will result in failure. So you have to figure out how to have them like you, what they will perceive as you demonstrating competence, and the true reasons they are looking to hire for your position, then you have to do everything to fit that description.

It could be something out of your control and discriminatory, like you aren't the right age, gender, or race, but hopefully that's not the case.

Either way, I'm sure that no matter what they are looking for, they'll have trouble turning down a strong candidate, so figure out what it takes to become one of those, then enjoy. Also, you may be applying to the wrong companies.

</comment><comment><USER3> 1\. Technical competence: the candidate is unable to satisfactorily answer even the most basic questions about 1 or more of the technologies/skills listed on their resume.

2\. Candidate ambitions / Job mismatch: this goes both ways. I have rejected candidates that were clearly just looking for the paycheck and would likely do the minimum necessary to not get fired. I have also rejected candidates that wanted to do a lot more than the position required and would likely get bored and move on quickly. (For the latter, I always try to find another position that would be a better fit, even if it's outside my group, company, or even industry.)

3\. Culture/Team mismatch: this is the last, and rarest reason to reject a candidate, and is only considered if they passed the two above hurdles. If the candidate's work/communication styles don't seem like they will mesh well with the existing team, this is sufficient to reject the candidate, although my team needs to feel pretty strongly about this incompatibility.

</comment><comment><USER4> I've been involved in a number of recruitment processes, on the employer side, recruiting technical people.

The main thing that I look for is a good balance of technical aptitude and cultural fit. I will generally prefer a person that can communicate well (in writing and in person) over a similarly technically skilled person that cannot.

Current skils are not usually as important as an ability and willingness to learn.

I don't like it when candidates are obviously just looking for a paycheck and really don't care what they'll be doing. These kind of punch in/punch out, 'take the money and run' people are a slowly debilitating cancer that it is super important to root out as early as possible.

So overall, I'd say for me it's attitude and communication skills more so than anything else.

</comment><comment><USER5> I've hired a number of people. I'm usually not too picky about knowing a specific technology. I'm more interested in the soft skills, as well as proof they'd be able to pick things up quickly.

My reasons for NOT hiring someone:

\- can't communicate well. I always ask them to draw something (like an ER diagram) and explain it.

\- doesn't show examples of initiative

\- doesn't seem passionate about career choice

\- no examples of previous work

\- (for recent CS graduates) can't explain something that should be part of standard CS study: eg NP completeness, what Big O notation means, etc.

</comment><comment><USER6> It was an interesting thing for me to do interviews, like the interviewee, and then hear the various objections of my peers. They were all over the map, more than any most common thing. All I can suggest is that you ask about the company's goals, adopt them, say you want to help ... basically insinuating yourself into the group as much as is polite in the setting.

(The thing I wanted was someone who wanted to help me get my project out.)

</comment><comment><USER7> Programmer who is looking at keyboard while typing code - not good enough.

<comment><USER8> were they just straight up staring at it like they didn't know how to type? I make the occasional glance to realign myself (even though i still use my index fingers to find the bumps on the home row keys 'j' and 'f') in the consistency that someone would check their mirrors when driving, just a habit, but shouldn't affect the code i write</comment></comment>


Beauty of the changing seasons (WebGL experiment) - <AUTHOR> http://www.rainyscope.club/?summer <comment><AUTHOR> Me too, pluviophile</comment>


Show HN: Catching up with movies is easy with flicktogether - <AUTHOR> http://www.flicktogether.com

<comment><AUTHOR> Hi everyone, this is something I've been working on during late nights and weekends. It's a social network for movie goers that allows you to cast your vote for movies that are currently playing in theaters then see where you and your friends overlap. You can also receive email notifications when new movies arrive in theaters!

Please let me know what you think. You can try it without signing up, but to vote, you must sign up. I currently only support facebook.</comment>


Using AngularJS to Pull Facebook Events - <AUTHOR> http://blog.austinkpickett.com/using-angularjs-to-pull-facebook-events/ Getting a bit comfortable with AngularJS and decided to whip up this little tutorial. There's a working demo at the bottom.
If you have any critiques on the language/code please let me know.
Thanks! <comment><AUTHOR> Hey all, I just wrote up this tutorial to pull in Facebook events. The working demo is at the bottom.

If you have any critiques on it, I'd love to hear.</comment>


USPS Redesign - <AUTHOR> http://grand-army.com/work/projects/project.php?project=usps_retail <comment><USER2> The two main typefaces are Knockout and Gotham, both being fonts from Hoefler & Co. — formerly Hoefler & Frere-Jones (H&FJ), until Jonathan Hoefler allegedly never gave Tobias Frere-Jones the equity stake he promised, eventually calling him just an employee[1].

Not only do I think is Hoefler & Co. a terrible company under Hoefler's leadership for that unethical move, the company has refused for the longest time to support web fonts using @font-face — now they partially support it, but only using their proprietary hosting platform, which is just setting a bad precedent for the open web.

There are plenty of small foundries producing high-quality typefaces, with @font-face friendly licensing for webfonts. Can we please stop using Hoefler fonts and supporting this guy?!

[1] [http://www.theverge.com/2014/1/17/5318206/hoefler-and- frere-...](http://www.theverge.com/2014/1/17/5318206/hoefler-and-frere-jones- lawsuit)

<comment><USER3> ideologically, i agree, except that HFJ/H&C produce some amazing timeless typefaces and it's really hard to ignore that.

<comment><USER4> Agreed, they own some of the most well known typefaces in the world. Sadly, their pricing is absurd.

For example, I run a forum with a million daily page views. If I wanted to use Gotham, I need to pay $150 for the font, and then subscribe to their cloud service and pay $450 per month for that amount of page views.

I might be willing to pay a one-time $100 fee to use one of their fonts, or a $100 per year subscription to use any of their fonts. However, $5,500 a year for my site? That's almost as much as my servers. It's a laugh, I'll stick with the well respected free web fonts.

</comment></comment></comment><comment><USER5> in my humble opinion, the "look" of the usps isn't their problem on the retail side. it's the fact that it's a complete and total PITA to ship with them, coupled with the wrong incentive structure for their employees.

1\. streamline the process - one form to ship something, a letter, a package, whatever. one sticker goes on the package to indicate the shipping class (certified, etc). none of this a sticker here, a red stamp there, etc.

2\. incentivise employees to be PRODUCTIVE. i don't know much about their existing compensation plan, but every time i go to a PO, no one seems to give a shit. i ship a lot of packages on my lunch break. the PO is PACKED at noontime... and there's one person at the desk. REALLY?

anyway, i could go on, but they have a long, long, long, way to go.

<comment><USER6> #2 is the #1 reason why I don't like dealing with the USPS for packages. It's easier for me to run to the post office and have them walk me through the process of the more complicated shipping (non-domestic primarily), but the people there are ass holes. Between the post office where I live and the office where I work (in two different states), I've never had a good experience. There's always some pissed off, rude middle aged woman who acts like I'm an idiot for not being familiar with all of their complicated protocols and rules for shipping.

So yeah, branding isn't their problem. It's the service itself that blows.

<comment><USER7> The most polite way to put it is people who willfully refuse to learn any market, are only given the alternatives of being frustrated or ripped off, often without understanding which is about to happen to them. So in this individual concrete example, basically you're saying that for a willfully uninformed customer, the USPS has made a policy decision at a high level to frustrate you instead of ripping you off, and you'd like to do business with someone who will rip you off instead of frustrating you. I donno if that's a huge win or if most people would really prefer that, especially if the alternative were explained to you.

I've shipped exotic electronics prototypes to Canada, all by myself, gettin it right the first time, about as exotic as you can get without involving ITAR, with only minimal and brief research. If you get ITAR involved, then I do feel your pain, but ITAR isn't the USPS's fault, even if they're the easiest people to lash out at.

<comment><USER8> There shouldn't need to be any learning of markets or navigating of postal office policies. This is a business like any other meant to serve their customers. Shipping a package should and needs to be as easy as checking out at Wal-Mart.

<comment><USER7> "Shipping a package should and needs to be as easy as checking out at Wal- Mart."

.gov politicians disagree emphatically. Those regulations weren't made for fun. They may result in a dysfunctional system. Monopolies do not serve their customers other than incidentally.

</comment></comment></comment></comment></comment><comment><USER9> Is OP affiliated? I like the work, but batch processing images constrained to 2700px, then throwing all 60 of them to load at one time is killing you. Mockups or not, you're getting some traffic, so optimize those images (resize to 50%; save as 8-bit png for fewer artifacts than jpeg).

</comment><comment><USER10> It's slow to load now, so if it goes down, here's an archive [http://web.archive.org/web/20140703023941/http://grand- army....](http://web.archive.org/web/20140703023941/http://grand- army.com/work/projects/project.php?project=usps_retail)

I agree with jrockway that the "Knockout" font is a little hard to follow. The eagle at the end looks... cool, but unnecessarily violent :p

</comment><comment><USER11> A fine example of design for the sake of design.

Is that an amateur proposal, or was this accepted by USPS, polished further and paid for? Based on the amount of text fillings, looks like the latter is true. In any way, what I see is highly impractical, and the brand book is far from complete. Here are some things I dislike about it:

-All caps. This is wrong, and it should be fairly obvious even to a child, when pointed out. Millions of people will see media based on it, and a generation will grow up, struggling to read all-caps price lists, all-caps footnotes and navigating all-caps menus on their smartphones. What's worse, is that they will subconsciously accept it as part of their lives and surroundings.

-Too much visual clutter: completely unjustified use of borders, underlines and dotted lines – also in between semantically same elements.

-What does "→" mean?

-Clickable elements are indistinguishable from statics on self-service terminals and smartphone apps. Footnotes are impractically small even for a HD screen.

Overall impression: somebody, truly oblivious of basic usability principles, thought that infographics ( _the Daily-Mail-grade ones_ ) and UITableViews are cool, and built a company identity around them. And the other guys sold it.

<comment><USER12> Can you point to some recommended reading for someone looking to learn about these design principles?

<comment><USER11> Sure! I am probably biased, but I have been following Artemy and his studio from the early 2000s. He publishes semi-random notes on design, some of them influenced by realities of a post-Soviet state. Here is a link to the book: [http://www.artlebedev.com/mandership/](http://www.artlebedev.com/mandership/)

</comment></comment></comment><comment><USER13> Everything looks better with Gotham, whether it's Obama, DC Comics, Twitter or USPS.

I also like Montserrat, free typeface kind of similar to Gotham, yet kind of different.

[http://www.google.com/fonts/specimen/Montserrat](http://www.google.com/fonts/specimen/Montserrat)

[http://www.fontspace.com/julieta- ulanovsky/montserrat](http://www.fontspace.com/julieta-ulanovsky/montserrat)

</comment><comment><USER14> It is quite bold and certainly makes an impression. If the post office looked like this, I think I would be confused for a few seconds as I wondered how I accidentally stepped into a personality-infused government building.

That said, I find this font incredibly hard to read; it almost feels like it's not English, and my brain has to work extra-hard to form words from the pixels on the screen.

<comment><USER15> I agree. It's almost painfully difficult in some places. I think the biggest problem here is the fact that _everything_ is set in all caps, which is a pretty big typographic no-no.[1] The wide tracking and narrow characters of the secondary copy don't help either.

[1] [http://typographyforlawyers.com/all- caps.html](http://typographyforlawyers.com/all-caps.html)

</comment></comment><comment><USER15> Looks like the server's getting hammered right now, so here's an article from Brand New about the redesign, with most of the same images:

[http://www.underconsideration.com/brandnew/archives/new_reta...](http://www.underconsideration.com/brandnew/archives/new_retail_experience_for_usps_by_grandarmy.php)

</comment><comment><USER16> Having worked on web projects for the USPS before 2000, I remember they had the design sense of a rock at that time. One web app I worked on was for internal use, I had to work with IE 2.X since they had actually paid MS for a license and shipped it to PO locations on a CD. They wouldn't consider supporting Netscape which actually functioned even though it was free. I guess "Welcome to the 21st century".

</comment><comment><USER17> A little nit-picky thing I have with the USPS's choices are their add-ons for tracking: USPS Tracking (end-to-end), Return Receipt (proof of delivery), Signature Confirmation (update to date tracking and proof of delivery) & Certified Mail (allows receiver to track delivery).

WTF - these are barely differentiated and only confuse people who don't mail things often. WWSJD (Steve Jobs) - probably have a single add-on choice he'd call something like PackageKit which would be $2 and include up-to-date tracking (for buyer and seller) and proof of delivery.

<comment><USER18> nobody cares about this in this thread.

<comment><USER19>
      nobody cares about this in this thread.

I care.

The branding, no matter how good looking it is - and it is good - must in the end enhance the product. But if the product itself is confusing, the branding and styles can only do so much. Concise product goals make the work of the designer more focused and the end result would be beautiful to use as well as look at.

</comment></comment></comment><comment><USER20> Before even looking at this, I predict Gotham.

Edit: It's painfully slow to load, but it seems I was right.

</comment><comment><USER21> I like it, but I ask myself if this design will resist the change of times.

</comment><comment><USER22> Looks good. I wish the US Government wasn't hosing the USPS...

</comment><comment><USER23> Time to bring back the American Letter Mail Company... though I'm sure some redesigning could be in order.

</comment><comment> o0-0o Not many people realize that the USPS is the ONLY federal government department authorized and mentioned in The Constitution. Cut the other departments, and give it all to the USPS because constitution.

<comment><USER24> Except it also delegate authority to Congress and the Gov't to do a number of things, and does not specify how those things should be done, allowing Congress and the gov't a great deal of freedom in implementation. So no, the USPS isn't the only constitutional government agency.</comment></comment>


How to stream torrents directly from your browser – no download required - <AUTHOR> http://www.techtuft.com/how-to-stream-torrents-directly-from-your-browser-no-download-required/556/ <comment><USER2> Except caching a torrent like this still 'downloads' it, you're simply letting your computer clear it's cache soon after your done with the file. So no, you're not getting round any download issues here. Streaming is downloading.</comment>


Aviation contributes 3.5% to the drivers of climate change that stem from humans - <AUTHOR> https://phys.org/news/2020-09-aviation-contributes-drivers-climate-stem.html <comment><USER2> The aviation industry points at this figure and says "hey, why are you bothering us instead of the cement industry?"

one aspect is that aviation is a (long term) growth industry although the players seem to think it's boring.

another is that paths to electrification are clear for the car but not so for airplanes.

part of it is that technology is not just "thirsty for hydrocarbons" but it is thirsty for the right kind of hydrocarbons. Back in the day we poisoned ourselves with lead to get desirable burning characteristics from gasoline. Methane is burned at the wellhead in places today because the price is so much less than heavier hydrocarbons.

Methanol, Ethanol, 1-Butanol, Biodiesel, DME, and similar fuels are qualified for use on the ground. Sustainable fuels for aviation use are maybe 30 years behind where they are on the ground. There is still desperate talk of building up the same hydrocarbons they use today via the Fischer-Tropsch process, probably the greatest technological "white elephant" in human history.</comment>


Show HN: WhatCanWePlay? Find games that you and your friends already own - <AUTHOR> https://whatcanweplay.net <comment><USER2> I love the idea of finding and playing games that me and my friends own. But, to be honest I do not play games too often. Isn't there any build-in solution for that? It seems like obvious problem.

I don't know, maybe I am just wrong.

<comment><AUTHOR> Steam has two semi-related features for this, but neither did what I wanted. You can click on a single user's profile and see what games you both have in common, or you can click on a game you own and see what other friends own it. This tool is just an extended version of that first feature to work with multiple users instead of just one.

I made this to solve a niche issue me and my friends had, where none of us knew exactly what we wanted to play, and each game we suggested wasn't owned by everyone. The name "What Can We Play?" is actually the phrase I've said every time this situation came up.</comment></comment>


ASUS Announces B250 Expert Mining Motherboard: 19 Expansion Slots - <AUTHOR> http://www.anandtech.com/show/11739/asus-announces-b250-expert-mining-motherboard-19-expansions-slots <comment><USER2> PS/2 ports? What for?

<comment><USER3> Maybe it's good for _very_ budget/retired KVM swithes. Probably makes it easy for the hosts to have a pile of servers, a pile of GPUs, and a single keyboard, mouse, and monitor to keep the prices down.

Probably was also already on the board design.</comment></comment>


Show HN: Open-Source Software as a Service (OpenSaaS) – Charged Hourly - <AUTHOR> https://www.orionian.com/ <comment><AUTHOR> I am excited to share this with the HN community. More apps will be coming out of beta soon.

It's worth noting that we are offering Cachet (Status Page) and InvoiceNinja installations completely free.

Our mission is to make it as easy to launch and, more importantly, maintain open-source applications as any SaaS provider.

A comparison may be found here: [https://www.orionian.com/comparison/](https://www.orionian.com/comparison/)</comment>