Ask HN: Scratched my own itch. Is one week too soon to pivot? - <AUTHOR>

Hi everyone,
I've written a bit of software that I needed.  I have packaged it and attempted to market it.  http://www.virtsync.com
With a few hundred dollars spent on LinkedIn and Google Adwords, there have still been no downloads of the evaluation version.
Is the site broken, or did I just have a unique need?  (I would have happily spent the $49 that I'm charging, if the software had already existed.)
Is there a way to turn this software into a profitable service, perhaps like rsync.net?  Or should I just forget it and get on with the next project?
Any comments on the site, software or future direction would be very welcome.
Thanks,
Chris. <comment><USER2> $49 per machine is a pretty high cost, particularly for something which is new and untested.

I'm no expert, but my gut feeling is that for this kind of tool - you need to offer a more 'enterprisey' offering. The way budgets for the kind of places that this tool would be useful are allocated, $49 for a single utility for every machine it might need to be run on is something that sysadmins might have difficulty explaining.

Bear in mind that the idea of syncing is not novel, and most sysadmins have built their servers around the current tools and constraints available. They are likely to look at your utility and think 'that's cool, but it's not worth the cost: what I have now works even if it takes longer, and I'm not paying anything for it'.

If you asked me to pay $49 for a faster version of rsync, which I then had to incorporate into my tool-chain, I'd probably just forget it. The cost of changing to a new utility is more than just the cost of the utility itself.

<comment><AUTHOR> Interesting thoughts. Perhaps I should change the interface so that it is drop in replacement for scp?

<comment><USER2> Sounds like a good idea to me - if users can try it out simply by installing it and either aliasing scp or modifying their scripts very quickly, then I'm sure more would be willing to try it out in a real-world scenario.

</comment></comment></comment><comment><USER3> You may find interesting this presentation from patio11 "Marketing Software, For People Who Would Rather Be Building It" [http://www.kalzumeus.com/2013/04/24/marketing-for-people- who...](http://www.kalzumeus.com/2013/04/24/marketing-for-people-who-would- rather-be-building-stuff/)

</comment><comment><USER4> Why not market a Windows version? As a Linux user, I'm accustomed to getting stuff for free. rsync also isn't as ubiquitous there so you don't have to complete with a free offering.

</comment><comment><USER5> I think $49 per machine is a lot. But the software interests me. The one thing I'd like to see is a speed comparison between rsync and this product. Also, is the underlying technology something that could be licensed?

For example, at CloudFlare we are generating 20GB of log files per minute and we need to move these around. Finding a fast way to do that is important. Clearly, CloudFlare could pay $49 per machine without a problem.

</comment><comment><USER6> It seems to me that being "way faster than rsync" is not worth $49. Also there is no comparison / explanation on the site of how it is faster than rsync.

</comment><comment><USER7> You've conducted a single experiment and found out that the LinkedIn and AdWords adverts you ran put nobody in your funnel. This is useful data. Come up with some more ideas for experiments to run and run those. Pivoting after a single marketing experiment though? Too soon.

</comment><comment><USER8> Pick up a phone and call 50 offices, push through to SysAdmin. Happy to break down why, but for now, try this.

Alternatively, but more difficult, track down some local IT integration specialists, resell through them.

All it costs is your time and possibly phone bills.

</comment><comment><USER9> Split test and try some new pricing models. This seems like something that should have the core free, with paid upgrades and paid support for large clients.

</comment><comment><USER10> Random idea: but if your service is so good but addressed to technical people, why not put it out for free (or even open source it) and offer paid support?

<comment><AUTHOR> Thanks, do you think the price is a problem? Is everyone conditioned to not realise that $10/mo for ever is more than $50 one-off.

Yes, sysadmins are the target market.

</comment></comment><comment><USER11> You only pivot when your tests point to it. Go test and make an educated decision.

</comment><comment><USER12> Doesn't this do the same as $ rsync --inplace?

<comment><AUTHOR> No, virtsync creates sparse files

The difference is important when you have many 50GB VM disk images with just 2-3GB occupied (as I have).

Rsync doesn't support --sparse --inplace.

Also the virtsync command line is more similar to scp than rsync. No need for any configuration files - it uses ssh as its transport.

<comment><USER13> I think one of the problems I'm having is figuring out where the product would fit in my workflow.

Are you looking for people with dedicated backup and recovery?

Are you looking for people without BaR but uses a lot of VMs?

Should I backup anything with this, or just my VMs and DBs? If so, how does it compare to [existing VM or DB backup system]

How does it compare to using rsync with hpn-ssh? Using hpn-ssh significantly improves rsync speeds, though I don't know how it works with sparse files since I use dedicated SAN backups for my VMs.

</comment></comment></comment><comment><USER11> Do some market research before giving up.</comment>


Please Don't Say Just Hello in Chat - <AUTHOR> http://www.nohello.com/ <comment><USER2> I originally wrote this text on an internal wiki page at Google. It was short- linked to "go/nohello" and sparked a fair bit of discussion, including another page with exactly the opposite viewpoint. I have no idea who Brandon High is, but he must have copied it from inside Google and posted it publicly.

<comment><USER3> Was going to say. He could have at least stole the other counter-articles as well.

</comment></comment><comment><USER4> 2010-07-19 12:00:00 co-worker: Hi

2010-07-19 12:00:30 me: Hello

2010-07-19 12:10:00 co-worker: I have a question about Facebook. Are you the right person to ask?

2010-07-19 12:10:25 me: May be. What's your question?

2010-07-19 12:20:25 co-worker: I want to know ...

2010-07-19 12:21:10 me: No, sorry. For that, you need to contact ...

Fast version:

2010-07-19 12:00:00 co-worker: Hi. I don't know if you are the right question, I want to know ...

2010-07-19 12:01:10 me: Hello. No, sorry. For that, you need to contact ...

<comment><USER5> So basically just skip hitting Enter..

<comment><USER6> As well as sitting there waiting for the person to type their next message.

</comment></comment></comment><comment><USER7> Seems like a problem that a scriptable chat client should solve: if it's the first message in a long time and it's short, debounce notifications for 30sec~1min.

Not a silver bullet but it might solve it in many cases

It reminds me of my old mIRC scripting days

<comment><USER8> Snap! Great suggestion there

</comment></comment><comment><USER9> IRC rules are still quite relevant, and "don't ask to ask just ask" is also still true.

<comment><USER10> Freenode can be like :

      Hi
      I have a question
      Is someone around to help me
      I already tried restarting but that didn't help
      [5 people quit]

</comment></comment><comment><USER11> I kind of disagree with this. If you post your problem to someone without asking if they have the time, it interrupts their flow to a much greater degree, because it's simply not possible to read that question without your mind engaging with it.

Posting just "Hey" is kind of dumb, but starting with "Hey, do you have a minute? I have an issue" is fine. It's easy to respond to with "no, sorry" and keep working.

<comment><USER12> "Hey, do you have a minute? I have an issue"

Except a lot of people are going to read that and then wonder – for what feels like an eternity – what's the 'issue' and how serious is it?

<comment><USER10> This. If I don't have time, I'll say "I can look at this at [time]" or just not answer if I'm e.g. presenting or something. It makes my life a lot easier when someone just gives me the facts, and it gets them to done faster as well. Pleasantries are fine and great, but in work chat, I don't consider it rude to just ask a question to someone directly. Ideally, a channel can answer, but sometimes you're working with someone specific on a thing. I also don't have a problem referring people to channels when I don't have time or don't want to get into the habit of answering that type of thing myself 100% of the time.

TL;DR help the person you want help from by doing the legwork of figuring out the exact error, and get to the point where you're asking an answerable question. Give them all the relevant details, and try to take as little of their time as possible. This, to me, is a sign of professional politeness and respect. It also tends to get you an answer quickly, and a high likelihood of that person helping you again in the future.

</comment></comment></comment><comment><USER13> So this is one way to do it. But it has its downsides too [and thus I find the webpage slightly pedantic for ignoring the tradeoffs]. I think the "Hello" is like "Syn." Cases where you may want to use hello are

1\. You need an immediate response, if they are afk then you don't want to ask them the question at all because you'll ask somebody else.

2\. You want to signal that you'd like to talk to them when they're free, but that your message is low priority. Generally I'd take a "hey" off-hours to mean "don't answer this unless you're on slack at your computer. Pong me back when you're in the office"

3\. Some people care more about the communication being natural and human interaction than they do responding to the maximal number of things in a day. If we have to sacrifice our ability to enjoy our intercations with other people for our job, I'd ask that we don't sacrifice without a fight.

<comment><USER14> staring a slack window after receiving "hey" and not doing the work i was doing before receiving said "hey" is very very aggrivating.

<comment><USER13> And I'm not trying to discount your experience, rather I'm trying to show that there are other people who have contradictory preferences... and raise the discussion from a "my way is objectively best!" to a conversation.

</comment></comment></comment><comment><USER15> If it bugs you just don't respond to the hello. If someone complains just say you were waiting for the actual content (no one just says hello on chat for no reason). You assumed that the hello was just to warn you that something longer was being typed and that you shouldn't immediately leave.

The nice feature of this approach is that you _can_ immediately leave if you know that you really don't want to deal with whatever it is that is coming and can legitimately say you never saw it.

<comment><USER16> Yup. I ignore a lot of "hey"s, if you respond then it just incentivizes more later. No one has complained but I'd just complain back about their inefficiency. If it's an emergency, they can call me twice.

</comment></comment><comment><USER17> While I question the need to make this an entire website. I completely agree.

I have people who do that all the time on Skype. Say hello first then I need to say hi back and wait for them to actually ask their question. It is such an absurd waste of time.

Just include your question in your first message! Please.

</comment><comment><USER18> I've personally found that I get _much_ better results when I say hello first, as opposed to including everything in a single message.

My hypothesis: When you ask someone a full detailed question, the other person sees the whole thing at once, as one big daunting block of text, and they decide to ignore it for a while. Conversely, when you message someone saying "hi", it builds suspense. They start to wonder what you're going to message them about. They pause what they were doing for the few seconds while waiting for you to type out your full comment. Often times, they even reply saying something like "hello" or "what's up". All this increases their buy-in into the conversation, and makes them feel more invested. As a result, when they finally get your actual question 20 seconds later, they are a lot more willing to reply immediately.

Is it time inefficient for the other person to have to sit around for 20 seconds while you're typing in your actual question? Yes, sorry for wasting 20 seconds of your time. But that's a trivial tradeoff in comparison to me getting the information I need so I can be unblocked and productive.

If and when people start to reply promptly to messages, I'd be perfectly willing to stop using these tricks and hacks. But until then... hi.

<comment><USER19> But writing a daunting block of text will often take more than 20 seconds. What you wrote comes off as an incredibly self-centred point of view.

If you're writing big paragraphs right off the bat, then perhaps you need to think about what your typing and refine things a bit more before you break someone's attention from what they are doing.

As Mark Twain wrote, "I didn't have time to write a short letter, so I wrote a long one instead." You shouldn't do this, even with instant messaging.

> If and when people start to reply promptly to messages…

And there's that air of entitlement again. There seems to be two wrong assumptions: First, that everyone is in front of their instant message client all the time; and second, that they're that invested in dropping everything they are doing to sink ten or twenty minutes of chat messages back and forth with you.

<comment><USER18> Since you've made a number of assumptions about me, let me make one about you as well. You sound exactly like the colleagues I've worked with who think that their time is more valuable than everyone else's. In reality, most research shows that helping others in an organizational context is strongly correlated with business success.

[https://hbr.org/2013/04/in-the-company-of-givers-and- takers](https://hbr.org/2013/04/in-the-company-of-givers-and-takers)

I am extremely selfless in helping colleagues who ask me for help, and I would like others to do unto me as I would do unto them. To me, that sounds perfectly fair, and well aligned with the greater organization's goals.

Regarding some specific points you made:

\- I spend a lot of time thinking about exactly what I'm going to say, even before I send the first hello

\- It typically takes me only 20-30 seconds to write out the message immediately following the hello

\- If someone happens to be busy and doesn't respond immediately to my message, I have no complaints. This is equally true whether or not I start off my message with a "hello", and is irrelevant to this discussion

<comment><USER19> There's a certain irony that your original comment sounded like you think your time is much more valuable than everyone else's too, which is probably why it's gotten so downvoted. In any case...

I probably do sound like the colleagues you've worked with. It's not that I think my time is more valuable than everyone else's, but I do this my time _is_ valuable. It sucks that your colleagues have treated you this way. I've worked with colleagues who would interrupt me every ten or twenty minutes, just when I'm getting back into the flow of concentration needed for programming which they broke ten or twenty minutes ago, often for what seem like very simple or trivial things. My frustrations with that probably bled through in my writing.

I also agree with the principle of treating others as I would like them to treat me. Looping that back to the original topic: that is exactly why I strongly prefer not to just receive a, "Hello," with a wait for response in instant messaging, but an initial message more in line with what the article suggests. This is also what I do when sending an initial message for the same reason: I value the other person's time and want to be cognisant of that.

<comment><USER18> There's certainly a balance to be struck between valuing your own time, and valuing that of your colleagues. I just think that most people tend to err far too much on the side of not helping a colleague in need. This is backed up by the study that I linked in my previous post as well.

In an ideal world where my colleagues have learned to find that balance, no such hacks are needed. But given the reality of most teams I've worked with, if using such hacks and "wasting 20 seconds of their time" is the price I need to pay, that certainly seems like the lesser of two evils.

</comment></comment></comment></comment></comment><comment><USER20> Ironically, in my experience, when I immediately ask a question, the (auto-)response will still be "Hi, I'm <name>, how can I help you today?"

<comment><USER21> It sounds like you are talking about customer support chat. The "hello" problem this article talks about is more relevant to chats between coworkers or friends.

</comment></comment><comment><USER8> Perhaps the client could help here? :-)

Other user types any of the common greetings alone (hi/hello/hey)

Client responds with: "this is an automated response - your greeting has been blocked until you provide a more meaningful reply"

Then filter out some rude/idiotic replies and keep filtering until the response's entropy is above a threshold and the sentence has some basic structure or presence of a couple of POS (eg a verb and noun)

<comment><USER7> Snap! Great suggestion there :)

</comment></comment><comment><USER22> You can always fill up your copy buffer with a question so as soon as saying hi, you can send the question.

<comment><USER23> This. I'm always afraid they might be presenting or otherwise showing their screen to someone who is not supposed to read my question.

</comment></comment><comment><USER19> This reminds me of a little anecdote. My colleagues in the office all used Skype, which was particularly handy for me as I was the only person who worked remotely (about half the time).

However, I always had the habit, when in the office, to eschew Skype and go see a person directly. It had the advantage of higher fidelity communication, and about half the time I'd figure out the answer to my own question before I got there.

After a while, I started turning Skype off when I was in the office (remember there were no other remotes at this time). This actually became an annoyance to one of my colleagues as they would have to, get this, walk across the hall if they wanted to talk to me. My ill concealed amusement at their ire did not go over well.

In person, face to face: the original instant messaging.

</comment><comment><USER24> I see the logic here, though I would forgive people who didn't grow up on the internet for treating chat like real life (where no-one says "hello" without a moment's pause after). I think people are slowly catching on that they can do what the post describes

</comment><comment><USER25> The reason why it's natural to do this is most of us don't want to waste time typing out a long-winded question if there's no one on the other side.

<comment><USER14> you can copy and paste that single question to the next person in the chain.. actually makes the workflow a bit easier

</comment></comment><comment><USER26> Absolutely DO say hello (or whatever intro, like a firstname) and DO wait for the other party to respond.

Why? Because I would hate to get "update: our quaterely results will be bad, we expect a 20% loss on our shares" popping up during a meeting just because I forgot to switch off the messaging app on my desktop.

I may be someone who is expected to see that but possibly not the other 20 participants.

A "ready for lunch?" can work without an introduction, though.

</comment><comment><USER27> I'll take "things that don't need their own domain name" for $500, Alex.

<comment><USER14> no it does. perfect tool for me. will use a lot. already pinned in the main channel

</comment></comment><comment><USER28> I just wait for the second ping (that usually has the details) before sending an ACK.

</comment><comment><USER29> Don't ask to ask just ask

</comment><comment><USER30> I strive to respect other people's time/concentration and I appreciate the same. So I typically start chats with, "Hey, do you have a minute?" to give them the chance to say no.

<comment><USER31> You already interrupted them. Whether they have a minute depends on what you want.

</comment></comment><comment><USER32> This argument has been beaten to death. People are not robots. Stop being obnoxious.

<comment><USER14> this helps them understand they are being obnoxious. i don't think they were aware</comment></comment>


Why 'Ok' Buttons in Dialog Boxes Work Best on the Right - <AUTHOR> http://uxmovement.com/buttons/why-ok-buttons-in-dialog-boxes-work-best-on-the-right/ <comment><USER4> Ok and Cancel are the wrong button labels anyway. The Apple HIG say that buttons should be labeled with verbs that signify the action taken.

For example, Cancel/No/Yes becomes "Don't Quit" "Don't Save" "Save". Much more intuitive, and it gives additional reason to put the positive button last: users should be encouraged to read all the options available before deciding—and can get the gist by reading just the buttons and ignoring the message.

Otherwise you get dialog box blindness. If you've ever observed someone doing this, it's maddening. They try something, a dialog pops up, they dismiss it, nothing happens (because the dialog box said "Can't complete this action"). I've seen people repeat this up to 4 times.

<comment><USER5>
        Save this document before quitting?

        <Don't Quit>    <Don't Save> <Save>

         </comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>-----

        Save this document before quitting?

        <Cancel>                 <No> <Yes>

<comment><USER6> Although, I've always preferred the Apple system of "Destructive"......"Neutral".."Constructive"

So that destructive operations are on the far left, isolated from non- destructive operations on the far right.

Yielding,

      [Don't Save]          [Cancel]  [Save]

Also, in a window title bar (more classical than OS X now),

      [Close]               [Minimize/Shade] [Zoom]

Any of the buttons grouped on the left side should be considered "destructive actions", and any actions on the right side should be considered "safe" or "non-destructive actions". However, this isn't the whole story. In cases where the main, intended action is destructive, the primary action verb should still be on the right, but the [Cancel] button should be the default enabled button (what Return key does when pressed)—e.g., emptying the Trash.

</comment></comment><comment><USER7> Here's an actual eye tracking study that comes to the opposite result of the linked article: <http://www.lukew.com/ff/entry.asp?571>

This isn't really surprising. The article claimed he just knew from experience and didn't need to do a test, so the whole article was just bullshit.

I was laughing out loud when he said users read all the options before picking one anyway, since I've seen that not happen in countless tests. Users don't generally give a crap about your interface, won't read instructions or screens fully, and will just scan and grab on to something that matches their current goal.

<comment><USER8> The lukew eye tracking study is for forms, not dialog boxes. And not just any forms, but it looks only at forms which have a list of left-aligned items which the user is working and scanning down. As stated: "the alignment of actions with a form's input elements provides a clear path to completion that helps people complete forms faster."

This article is about dialog boxes. They are different. Dialog boxes usually have no form input elements and usually do not have a list of items all aligned on the left like on the lukew tracking study.

</comment></comment><comment><USER9> "...if you're a knowledgeable and experienced designer ... then you can solve this problem through design analysis [as opposed to user testing]"

But if you're an empirical scientist you will use user testing to confirm or deny your hypothesis rather than assuming your rationalisations hold in the real world.

<comment><USER10> Exactly. Most of the article was based on some sort of unjustified "innate" knowledge of how users behave. He dismisses platform consistency as being unscientific and then goes on to present his own equally unscientific arguments for ignoring the convention. In the face of these two alternatives, I'd choose platform consistency every single time.

<comment><USER11> Designers work like this for good reason. Yes it reads like unproven pseudo- science, and it is, but there is reason behind this. When you work with thousands of concepts like this every day you can't empirically test them all across all cultures and environments (it would take forever and a day!) - <USER2> just develop a thought of what makes sense for you and have a basic think about why that might be so. This may not hold for all situations, but its going to be on average a better opinon than that of most other people (who will put a dialog box in one order or other without even stopping to think about why).

<comment><USER12> Kind of like how when you're going to choose a variable name, you don't do a linguistic study first?

<comment><USER13> Well, ultimately it's the balance between your time and you user's time.

</comment></comment></comment></comment></comment><comment><USER14> I still can't stand this in Android 4.0

Yes/No, OK/Cancel, Open/Close, On/Off, Come/Go, Stay/Leave, Buy/Sell, Gas/Brake, Thanks/No Thanks...

In English anyhow we are used to Positive option first, Negative option second... it's how our language flows and thus how we think. We read Left to Right... we expect the positive option on the Left, i.e. first, and the negative option on the Right, second. Just how I view it anyhow. To me it feels backwards the other way around and I don't feel that's just a learned convention. I will continue to curse Android 4 every time I mis-click on a dialog.

<comment><USER15> In most of the world, though, it's Brake/Gas.

And I personally prefer Cancel/OK because I usually want to click OK and my right thumb happens to be on the right side of the screen.

<comment><USER16> That just because if you had gas in the middle it would be uncomfortable for long drives.

It's the same reason the clutch is on the side as well, not in them middle.

I suppose you could swap the cluch and gas (leaving brake in the middle) - <USER3> clutch comes first, then gas, so the convention of first on the left is realized.

<comment><USER17> There was a Top Gear episode that looked at the history of the location of the pedals, and tried to find the first auto that laid them out the way we are used to today.

What was shocking is the enormous variety before then. Just about any of our familiar controls (including some others before we really got a good transmission system) could be on any of your 4 limbs.

</comment></comment></comment></comment><comment><USER18> Platform consistency has to come first, but I agree with the argument that OK/Cancel is backwards.

Apple chose those labels (as Cancel/OK) for the buttons in the original Mac dialogs in 1984. They tested other pairs, but those two labels won. With those two labels, order matters _a lot_.

"Cancel" is the more meaningful word of the two. You've just told the user that something unexpected will happen if they proceed. "OK" can be construed to mean "OK, well then obviously don't do that!"

So yeah, platform consistency first. But Apple tested that stuff back in the early 80s, those two labels won, and (in addition to all the reasonable arguments in the article), that's the only rational order for those two labels. Microsoft got it backwards and trained millions of people by confusing them until they learned. Gnome aped Microsoft.

And here we are.

<comment><USER16> Actually Cancel/OK is backwards. :)

I had to swap their positions in firefox - one of the first things I changed when I ran it for the first time.

> "OK" can be construed to mean "OK, well then obviously don't do that!"

And yes can be construed to mean "yes don't do that" - come on, that's a completely ridiculous argument!

<comment><USER18> "OK" can mean: "ok yes you've changed my mind, I agree, bad idea".

"Cancel" _never_ means: "cancel and proceed".

<comment><USER12> "Do you really want to cancel?" Cancel/OK

<comment><USER19> Double clicking a "No" button should mean yes, of course.

</comment></comment></comment></comment></comment><comment><USER20> I think the article's explanations for button-ordering are good but I wish their examples didn't violate other dialog design principles in the process.

One mistake their examples make is to include an "X" (close) button in dialogs that contain button choices. The "X" action is ambiguous in dialogs and is especially bad if all actions are equally probable (e.g. "Don't Save", "Cancel" and "Save" all seem likely to map to "X"). GUI toolkits don't seem to force any consistent interpretation of "X", and in fact the programmer might forget to wire up the "X" to any action at all. It's preferable for the "X" button to not be there so that the user can focus on the action buttons.

Another (admittedly minor) issue is the spelling "Ok". It's not pronounced "awk" or "oke"; it's both spelled and pronounced "OK". It _does_ have a whole- word form and that word is "Okay". So it can either be "OK" or "Okay" but it should not be "Ok". In dialogs it is very conventional to use the short form of "OK".

</comment><comment><USER21> I suspect most (moderately) experienced people see the OK/Cancel pattern as a unit and don't scan the whole thing before deciding and clicking.

<comment><USER22> To me, this seems like a great example of unnecessary optimization. Yes, the number of "visual fixations" is slightly less but in the grand scheme of a person's day, we're talking about a difference of milliseconds, if that. Aren't there far more egregious examples of UI design to spend time agonizing over?

<comment><USER21> Well, to steal a riff from Steve Jobs, milliseconds per day * days over years of use * tens/hundreds of millions of users (if you're designing the conventions for a big platform) = years or lifetimes. I'm just not convinced by the reasoning.

<comment><USER22> Yes, I've heard that reasoning over and over again and it just doesn't hold water at all for me. "Time-saving" just doesn't work at that level of minutiae.

Again, it's simply optimization where none is needed.

</comment></comment></comment></comment><comment><USER23> Come on guys, claims with no backing data?

The author writes "user testing is probably your best bet. But if you're a knowledgeable and experienced designer who can think about problems from the user's perspective, then you can solve this problem through design analysis."

This is so wrong. Actually design analysis can turn out to be completely wrong. You need to test it, get some numbers, and then you can claim that conclusions of your analysis are correct. Right now it's just a claim that may or may not hold.

</comment><comment><USER24> Created an account just to say this...

This is the wrong question all together. Yes/No is the wrong idea. Think about labeling the buttons Save/Reboot/Cancel, This allows the user to be sure they are going to get the expected results.

<comment><USER25> And if you do that you _force_ the user to read all options, which is completely unnecessary.

If the question is "Reboot?" and you have Yes/No as alternatives I will see that it is a Yes/No-dialogue-box instantly, way before I read the buttons I see the button structure and recognize it as a typical Yes/No-dialogue-box.

I read the question and because I already know my alternatives I have go directly to the option I want, if the buttons change every time I have to read and assess the situation every single time. This is good for critical questions (like, do you want to format this drive?) but bad for common questions (such as Save?).

The author never even considered this, which is exactly why you should follow platform conventions. If you don't people are going to feel weird coming to your application and even if you manage to gain 10% in comprehension by switching to a non-standard layout you are going to loose 80% in comprehension and 10540% in speed just because you are different than what the user expected.

Android ICS changed the place for the Cancel/OK buttons when unlocking the sim-card, my muscle memory still haven't learned this despite using ICS for many months.

The only thing this article managed to get through to me was: follow your platform guidelines.

</comment></comment><comment><USER26> Never take GUI advice from a web site that hardcodes the width of its paragraphs to 600px.

Seriously, who does this in 2012?

<comment><USER27> People who understand, that there is such a thing as optimal line length, and that line running across 24" monitor does not have it?

<comment><USER26> While this is theoretically correct, it goes against the principle of the web.

Write the content, provide some structural guidance (paragraphs, item lists, etc...) and let readers decide how to render it.

</comment></comment></comment><comment><USER28> I know I read somewhere (but I can't remember where now), that it's far superior to put the actual actions you're doing in the buttons, rather than a completely non-descriptive OK/Cancel.

Not "Do you really want to quit? OK / Cancel" but "Do you really want to quit? Quit / Cancel".

<comment><USER29> Maybe the Apple HIG <[https://developer.apple.com/library/mac/#documentation/usere...](https://developer.apple.com/library/mac/#documentation/userexperience/Conceptual/AppleHIGuidelines/Intro/Intro.html>); ?

</comment></comment><comment><USER30> Picture 1, "Less Visual Fixation": I think it is wrong, if I'm processing simple (or repeating) stack of windows I do not read all labels (at least after a few similar tasks), I see OK button and I click it.

Picture 3, "Maps to the expected button functions" This is also wrong, there are specific labels for actions on the picture - Back/Next, Backward/Forward, Return/Continue.

Picture 4, "Gives users a more efficient task flow" I agree with eyesight map (left to right, up to down) and this is precisely why OK should be on the left side - so we don't need to read further.

I confess that I'm Windows biased a little. But the author is biased just the same, only he is using Mac :) .

</comment><comment><USER31> To me the assertion that users read buttons the same direction they read text is bogus.

I'm an OS X user and I'm trained to read the right most button first as it has the description of what will happen (Save, Log Out etc.) Often it means I don't even have to read the rest of the dialog.

As others have pointed out, this indicates the whole idea that users will read all the options is bogus. But even when I do read them all (marginally complex set of options presented, or high risk scenario) I read the right most one first before skipping back to read left to right because I'm trained to skip to the right most button at the bottom of a dialog.

This invalidates much of the analysis on visual fixations and comes to the conclusion that placing the primary action on the left actually makes it easier under certain conditions (it's easier to track back to the left most button than to the right most).

It just goes to show that training can affect behaviour. If you did extensive eye-tracking tests explaining you're looking for high accuracy, with people who are unfamiliar with technology or who are used to the primary action being on the left, placing the primary action on the right will lead to less effort. But as the user is trained, the effort would probably increase.

</comment><comment><USER32> I disagree that OK/cancel are backwards. Placing OK on the left makes it a more deliberate choice. Thus the system can be more confident the user consciously chose OK, as it takes a smidge more effort to get there. OK/Cancel dialogs are (unfortunately) very common, it's very easy for users to become numb to them and just click whatever it takes for them to go away.

For similar reasons, Mac OS Classic placed the trash can in the lower right corner of the screen. If you had dragged something that far, there was nothing else you could possibly be shooting for. Therefore making the system more confident you were actually dragging that file to the trash. Which is one reason MacOS never asked "are you sure you want to delete that?" like Windows's recycle bin does by default.

Another similar example: MacOS classic placed the close button of Windows on the opposite side, on its own. Again, if you are clicking there, the system is more confident that closing the window is what you're really after. It's interesting to note that OSX did away with many of these well thought out devices.

<comment><USER31> I don't understand why putting "OK" first makes it a more deliberate choice. Why does it take more effort to get there? If a numb user's objective is to make it go away as quickly as possible they will become trained to where the "OK" button is and click it without reading anything else.

</comment></comment><comment><USER33> "If you're an inexperienced designer who doesn't trust your own judgment, then user testing is probably your best bet. But if you're a knowledgeable and experienced designer who can think about problems from the user's perspective, then you can solve this problem through design analysis."

... I really like the `either go with me or your an idiot` push... false dilemma anyone?

</comment><comment><USER34> These arguments obviously only work for left-to-right scripts. For RTL scripts such as Arabic, you want exactly the opposite.

</comment><comment><USER35> I believe studies on this are worthless. Show 2-3 modals to a user and he/she tends to understand where the positive button is & where the negative button is. Its more about habit than of user experience.

No one actually reads that many lines of text.

</comment><comment><USER36> I'm surprised Fitts' law hasn't come up. While not exactly the same domain as Fitts (minimize the need for fine motor control for a potentially gross action by placing the active area at the end of a gross movement, e.g. pointing to the edge of the screen) it would seem that gaze would be easier to fix on the edge or corner of a dialog, rather than somewhere in the interior.

<comment><USER31> The article does rather skip over that and starts by assuming that regardless of ordering you're aligning your buttons to the right of the dialog.

You could go with OK/Cancel and left align the buttons so it's easier to find the OK button.

Windows seems to go with OK/Cancel right aligned, which would be a little odd given the point you made.

I guess the use of whitespace to visually group the buttons makes it easy enough to find the button group and from there you read them left to right.

Would definitely be a interesting study to see the relative effects of aligning things to borders and visual grouping through use of whitespace.

</comment></comment><comment><USER37> How did we end up with OK/Cancel in the first place?

When I run into an OK/Cancel box (usually on a web page using the generic built-in confirm()), it often feels to me like the meaning would be far more clear if the options were "yes" or "no", no matter which order they're displayed.

Is there a UI 'best practice' reason OK/cancel "won" over yes/no?

<comment><USER31> I'm sure the Macintosh wasn't the first to go with OK/Cancel, but an interesting anecdote none the less about why "OK" won out over "Do It" [http://folklore.org/StoryView.py?project=Macintosh&story...](http://folklore.org/StoryView.py?project=Macintosh&story=Do_It.txt&characters=Larry%20Tesler&sortOrder=Sort%20by%20Date)

</comment></comment><comment><USER38> It's a rational explanation that just happens to be ... wrong.

Cancel/OK suggests Cancelling first, OK'eying second. Whether your eye has already moved on from Cancel is secondary to the fact that you brain got implanted with Cancel as a primary option.

<comment><USER31> Unless you're trained to start with the right most button (something the article ignores).

Also, positioning isn't the only factor - you can also highlight the primary action with colour and texture, which I would guess is far more effective at implanting a button as the primary option than positioning. Most OS's do this as a part of their keyboard accessibility.

</comment></comment><comment><USER39> Better yet, avoid modal dialogs.

</comment><comment><USER21> BTW, what's caused me more confusion than any of this is Cancel vs. the third option: "hit Back button on browser/phone / Close button on dialog"

</comment><comment><USER40> _Users will look at all of their options before they choose which action to take_.

Nope.

</comment><comment><USER41> +1 and yet, most arguments will end up toward the direction of "platforms consistency," especially on Facebook-related application since they have it "OK" | "Cancel" order.

<comment><USER42> I agree that in the long run it would be better for users; yet as a user, I'm used to clicking on the Okay button on the left. Every time I see one isolated application with the Okay button on the right, I'm going to have a slower/harder time knowing which button I need to press.

If one of your users uses 50 applications, and he uses yours once in a week, he's going to be annoyed at your application for being different; even if that "different" is supposedly better, reflexes have taught the user to scan the buttons in a certain way.

I'm not suggesting that the order we have now is better; but until one of the OSs or an application like Facebook moves to the "better" button order, I can't see why a designer might do so for his own application.

<comment><USER43> I agree, platform consistency is more better for your app than following something which is theoretically better. I'd be reticent to change the Ok -> Cancel order without some harder evidence than this.

<comment><USER43> "More better"? Jesus I should proof a bit...</comment></comment></comment></comment>


Eagles singer Don Henley: EFF, Google "aid and abet" criminals - <AUTHOR> http://arstechnica.com/tech-policy/news/2011/08/eagles-singer-don-henley-eff-google-aid-and-abet-criminals.ars <comment><USER2> "I hate the fuckin' Eagles, man" -- The Dude.

</comment><comment><USER3>
      There is no First Amendment right to infringe intellectual property rights.

Neither is IP a constitutional right, only the congress' ability to create IP laws.

I still find it fascinating how a single industry that's currently experiencing the same 'problem' as hundreds of industries and markets before them - namely, being made obsolete by technological advancement - is the first that thinks it is entitled to some sort of special rights to save their failing business model.

</comment><comment><USER4> I can't believe how transparent Don Henley's arguments are. How on earth does "everyone who runs a website" have more of a special interest agenda than "the music industry"?

</comment><comment><USER5> Who gives a shit what Don Henley thinks about the Protect IP act? Why not ask Ja Rule or Kim Kardashian what their opinions are? Bad form, Ars. Bad form.

<comment><USER4> They did include some of the EFF's response, and both parties' statements are indicative of the situation as a whole.

Personally I thought it was slightly interesting to see an actual musician's opinion rather than a nebulous "music industry" representative.

</comment></comment><comment><USER6> Of course they do. I do too: If I'm on the left side of the road, and a car wants to get by me, I'll get out of their way so they can drive past me in excess of the speed limit. No big deal, and no one gets hurt.

<comment><USER7> The suggested law is like a police car who can't catch the speeder, so instead takes the easy target and fines the guy who didn't actively stop the criminal. After all, he deserved to catch the guy, so surely he deserves the fine money too? We'll just make whoever is most to blame pay for it.

</comment></comment><comment><USER8> I wonder if Don Henley knows the record companies are now trying to define musicians legally contract employees. All that music Don Henley recorded wouldn't belong to musicians. Musicians would be contract labor. Those rights would all belong to the record companies.

<comment><USER9> _All that music Don Henley recorded wouldn't belong to musicians._

That was already happening. It is (or was) rare for artists to own the rights to their own works.

</comment></comment><comment><USER10> Sadly, the following Mojo Nixon link has now become obligatory:

<http://www.youtube.com/watch?v=QKWaCOQre4A>

To think that I've been reduced to such things. Say it ain't so, Don Henley!

</comment><comment><USER11> > _Critics of this pending legislation need to be honest about the company > they keep and why they essentially aid and abet these criminal endeavors._

Music is the only business where you can get away with calling potential buyers of your product "criminals".

<comment><USER12> How so? Aren't most people who steal physical goods, such as cars, potential buyers of cars?

<comment><USER11> But the auto industry is not accusing search engines, and anyone else who opposes the PROTECT IP Act, of aiding and abetting criminal behavior.

</comment></comment></comment><comment><USER13> How many here who live in the states still torrent copyrighted material?

The Internet is an awesome thing but it's killed and killing a lot of industries and jobs. Jobs as Jeff Jarvis has pointed out (<http://bit.ly/prM2gN>) will not be replaced, rather they are gone forever. From the newspaper industry chain, to the hundreds of thousands of jobs to be lost in the postal service soon, the annihilated music business and soon the cable TV and retail industries.

Millions of jobs are lost and going to be lost. Thus I wonder if you still download torrents in the US how do you justify doing so? Also how old are you?

<comment><AUTHOR> Francis Ford Coppola:

Q: How does an aspiring artist bridge the gap between distribution and commerce?

A: We have to be very clever about those things. You have to remember that it's only a few hundred years, if that much, that artists are working with money. Artists never got money. Artists had a patron, either the leader of the state or the duke of Weimar or somewhere, or the church, the pope. Or they had another job. I have another job. I make films. No one tells me what to do. But I make the money in the wine industry. You work another job and get up at five in the morning and write your script. This idea of Metallica or some rock n' roll singer being rich, that's not necessarily going to happen anymore. Because, as we enter into a new age, maybe art will be free. Maybe the students are right. They should be able to download music and movies. I'm going to be shot for saying this. But who said art has to cost money? And therefore, who says artists have to make money?

In the old days, 200 years ago, if you were a composer, the only way you could make money was to travel with the orchestra and be the conductor, because then you'd be paid as a musician. There was no recording. There were no record royalties. So I would say, "Try to disconnect the idea of cinema with the idea of making a living and money." Because there are ways around it.

[http://the99percent.com/articles/6973/Francis-Ford- Coppola-O...](http://the99percent.com/articles/6973/Francis-Ford-Coppola-O..).

<comment><USER13> Who says then the operator of torrents sites have to make money? Which they are making a nice profit running those sites. Name a torrent site that isn't raking in the dough?

Can you answer me why these torrent sites are raking in the dough? What is attracting their traffic and visitors?

<comment><USER14> > Who says then the operator of torrents sites have to make money?

People willing to give them money.

> Can you answer me why these torrent sites are raking in the dough? What is > attracting their traffic and visitors?

Convenience and a catalog that beats any other out there. You'll always have pirates, but the vast majority do it for convenience, not trying to avoid spending a couple bucks.</comment></comment></comment></comment>


The reusability fallacy – Part 3 - <AUTHOR> https://www.ufried.com/blog/reusability_fallacy_3/ <comment><USER2> >The latest paradigm "Microservices" became popular in the mid 2010s.

Microservices isn't for re-usability. It's main benefit is better encapsulation, which should let you do independent resource management/deployments/failures.

>If we look at reusability, we notice that this is the tightest form of coupling possible: If the reused part is not available, the reusing part cannot complete its work by definition.

What? This is a weird nothing-burger of a sentence. Why can't multiple components re-use some resource without gracefully handling any failures? Why does re-usability mean "cascading failures by design"?

>An important property of reuse is that the reusing part ... does not work without the reused asset ... The reused functionality is an integral part of the solution that (re-)uses it.

Oh, I see: because the author has defined it this way. Then the article goes on to try to argue a semantic difference between "usability" and "re- usability", in that usable components can be re-used independently, but in a way that can gracefully fail! So the whole thing is just begging the question.

There's no argument here as to why I can't write a distributed component with an eye to it being re-used in the future. There is no criticism of re-use in distributed systems. The only criticism is of tight coupling, which is totally valid, and then saying that re-use _demands_ tight coupling, which is not substantiated.

<comment><USER3> I think the concept the author is talking around here can be stated more simply:

When you _refactor_ software to reduce duplication, you _by default_ are increasing coupling.

At the start, you some lines of code that were just sitting in the bodies of two different functions. Now, both of those functions call one shared function. But, in a proper minimal-change refactoring, you didn't change the semantics of the code by doing this. So the shared function is still acting the way that its parents did: as sets of lines sitting in the bodies of functions. There's no circuit breaking or graceful failure there, because there was no circuit breaking or graceful failure in the original, non- refactored code.

Another way to put this is: compression makes data more fragile, in the sense that small numbers of bits can be "depended on" by more bits in compressed data than in uncompressed data. Direct duplication-elimination refactoring is, essentially, just compression.

To actually get robustness, you can't just do this kind of refactoring and then stop; you have to continue on and introduce a stable API to your factored-out function/component/service, with a specified interface. Once you do _that_ , then you cancel out the increase of coupling, because now everything is just coupled to a description of the interface. _Then_ you get the ability to re-use the function/component/service. Until you do that, though, you just have something that is known to work exactly in the use-cases it was extracted from; and which _shouldn 't_ be expected to work anywhere else.

<comment><USER2> I'd agree with you for this post, minus the weird re/usability semantics, but that interpretation goes against the previous parts of this series.

If you read Part 1, the argument is largely against _even well-architectured_ versions of re-usability. The author takes issue with all components designed for drop-in future use, believing that each problem requires a tailor-made solution.

The re/usability debate seems weirdly entangled with the coupling debate for no good reason. The author believes re-usability means tight coupling, and "usability" means good APIs with loose coupling (which can be re-used...).

</comment></comment></comment><comment><USER4> Szyperski also said this back in 1997. "Maximizing reuse minimizes use"

[https://books.google.ie/books?id=U896iwmtiagC&pg=PA45&lpg=PA...](https://books.google.ie/books?id=U896iwmtiagC&pg=PA45&lpg=PA45&dq=maximize+reuse+minimise+use+szyperski&source=bl&ots=FH0S7vrsaI&sig=ACfU3U1xIujcH8XOMiFlg7lXUWS4KHaR7g&hl=en&sa=X&ved=2ahUKEwiU7ufNyr3oAhVKSBUIHaXgBxEQ6AEwCnoECAUQAQ#v=onepage&q=maximize%20reuse%20minimise%20use%20szyperski&f=false)

</comment><comment><AUTHOR> Part 1: [https://www.ufried.com/blog/reusability_fallacy_1/](https://www.ufried.com/blog/reusability_fallacy_1/)

Part 2: [https://www.ufried.com/blog/reusability_fallacy_2/](https://www.ufried.com/blog/reusability_fallacy_2/)

Part 1 was posted previously but without much discussion: [https://news.ycombinator.com/item?id=22583605](https://news.ycombinator.com/item?id=22583605)

</comment><comment><USER5> The "fallacy" breaks down pretty quickly when we consider its implications. If we were to follow the suggestions given, we shouldn't be using:

\- Email services such as SES or Sendgrid

\- Password auth services such as Firebase

\- Chat services such as Twilio

You might say those are extreme examples, and that's the whole point. Clearly there are a ton of use-cases where it makes sense to build reusable services once, and using it across many clients. Not just for "enhancements", but as an integral part of your service's functionality. So how and where do we draw the line between reusable services and avoiding service-dependencies? That's the real question we should be asking, and one I don't see being answered in the article.

<comment><USER6> I look at it like this. It's super useful to have a screwdriver that has an adaptor that will take many different kinds of bits. It would be super painful to have a really configurable bit that could with some work fit any screw.

My exemplar is a library for doing things with grids. It supported any kind of 2d grid. It was an amazing piece of design from a conceptual standpoint. Super generic, clean and with some impressive demos doing very non-standard things. It was also much easier for me to write my own grid implementation for my usecase than learn how to use.

Being reusable because you do something well is great. Being "reusable" because you can be made to do one thing out of a bunch once you learn how is not. From a business point of view it's about how valuable that flexibility is and generally I think if it's not part of the core business you are better finding an inflexible fit rather than a flexible thing you have to sculpt to work. Simply because the latter takes focus away from what you are actually trying to do.

<comment><USER7> > _It would be super painful to have a really configurable bit that could with > some work fit any screw._

Why would it? Universal sockets exist: [https://images-na.ssl-images- amazon.com/images/I/61UczrhrTuL...](https://images-na.ssl-images- amazon.com/images/I/61UczrhrTuL._SY355_.jpg) \- I can imagine one built with small enough pins to push into/around any kind of screw head, although I don't know if one exists today.

<comment><USER6> The super complex generic grid library is also probably useful for someone but I'd say neither case is more universally useful due to the complexities involved.

</comment></comment></comment></comment><comment><USER8> I think about reuse in a couple of different ways.

I do not copy paste the same exact code multiple places. Then i use the same code.

If the code is not exactly the same, it's not a copy, hence it's not up reuse.

I do not generalize code before 3rd strike and refactor can be applied, and then I still use a lot of time thinking if it might a premature optimization.

I write microservices the same way as i write methods. If i copy and paste the exact same microservice, it might be up for reuse (3 strikes). If it's reuse, the same specifics applies as when programming a method or type.

I would never ever write any new code with reuse in mind. It's arrogant to think one can forsee the future, and that's exactly what writing for rejse is about. Start small, evolve.

</comment><comment><USER9> Java has the opposite problem. One of the often repeated taglines is "If you're unhappy with X, you can easily replace it with Y, Z, or Q!"

I just want one well-working thing, not twenty alternatives - seven of which turn out to be abandoned, three incomplete, one only works with Java 15 beta, and two are actually forks of the same abandoned pre-Oracle blogpost from Sun.

<comment><USER10> Java has that "problem" because it is in wide use, and Java is good at compatibility. Any popular tech is going to have many variations

</comment></comment><comment><USER11> Like my own his English is good but not _that_ good. His seems the right way to explain (there probably is a formal description for the style of writing (and a word for it in German)) but when reception is not guaranteed (I keep feeling like I almost got his point.) I would lower myself to explaining by code example. Something like a "hello world" of usable vs re-usable. Someone more skilled in the art should probably address note 6 ( [https://www.ufried.com/blog/reusability_fallacy_3/#fn:6](https://www.ufried.com/blog/reusability_fallacy_3/#fn:6) )

I did recall a thought I had some years ago that I will describe crudely because I'm lazy:

Parts of applications, by popularity, should be re-implemented in API's.

Parts of API's, by popularity, should be implemented in modules.

Parts of modules, by popularity, should be implemented in frameworks.

Parts of frameworks, by popularity, should be implemented in (higher) languages (then lower)

Parts of languages, by popularity, should be baked into hardware.

(Unpopular parts should migrate the other way around but that is not important right now)

</comment><comment><USER12> What do we mean by "software reuse"? I propose this definition: Software reuse happens whenever a given piece of code is called from more than one other code-location.

That means whenever a function has more than one caller we have reuse. Or when a web-service request is created from more than one code-location, we have reuse.

Is there an official definition for what "software reuse" means?

</comment><comment><USER13> From my experience actual good reusable code are very small and usually relatively simple great specialized task. As the component get more features, and when you use it, you are in a trade off situation where this works, but it doesn't fully do exactly what the requirement needs orbit does way more than it needs</comment>


Kingston announces 1 TB USB 3.0 Flash drive - <AUTHOR> http://www.engadget.com/2013/01/07/kingston-1tb-flash-drive? <comment><AUTHOR> Jeff Atwood recently wrote about how fast USB 3 flash discs feel -- [http://www.codinghorror.com/blog/2012/11/a-ssd-in-your- pocke...](http://www.codinghorror.com/blog/2012/11/a-ssd-in-your-pocket.html)

I just want to say, that after trying it out for myself... it really does feel really different. I'm used to backing up 10 gigs of data at times... what I would ordinarily get up and do something for to wait it out now takes literally 10 seconds or so. Everyone I know who deals with big data (well, in orders of gigs -- not going beyond 5 TB or so :)) has similar sentiments about how fast USB 3.0 flash discs feel.

</comment><comment><USER2> got a few verbatim usb3

measuring it on a usb3 host, they have a write buffer for the first 100mb or so... i can write to them at 90Mb/s... but after that, i got a stable 7Mb/s. and i bet this is the standard for all brands.

reading is fine all the way at ~95Mb/s

that said, my HTPC runs off two of those drives in a USB2 port and it's fine.

edit: regarding the coding horror link, i would never base my drive speed test on windows 8 copy dialog...</comment>


Apple Continues to Resist Bringing Flash to iPhone - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2008/11/18/AR2008111801618.html

<comment><USER2> Flash continues to not be on the iPhone and this story continues to be news. I don't get it.

<comment><USER3> and most iPhone users continue to not care.

</comment></comment><comment><USER4> I can't decide if this is a good thing or a bad thing. The only reason why I'd want flash on my iPhone is for some websites...but a lot of those rely on the assumption that the user is using a mouse. Lots of menus are difficult to navigate without mouseovers, etc.

I also don't think Flash will be the iPhone's undoing. What's the biggest use of flash nowadays? Youtube and the like, and possibly _some_ apps like games. Some games will be nearly impossible to play, and Apple already took care of the Youtube aspect...

</comment><comment><USER5> If I were SteveJ, I'd also block it. The iPhone App Store is going to be a substantial source of revenue. Why would I let people bypass the store and get apps through Flash for free?

<comment><USER6> Becuase those people are your customers, and you want them to upgrade to the next version of iphone instead of switch to another, superior phone.

I'm not saying there is a superior phone out there, yet, but this is one of the many features I'll be comparing when my current iphone contract is up. Most phone consumers are fickle -- apple will not be exempt from this in the future.

<comment><USER7> I think Apple's counting on no company making a phone that's close to as good that also supports Flash. To be fair, so far no company's competing very well.

</comment></comment></comment><comment><USER8> Question: do any of you know any iPhone users who _want_ Flash on their iPhones?

</comment><comment><USER9> Good for them.

Flash is good for animation, as in vector graphic pictures with movement.

It is in no way a superior form of video, as in actual movies.

<comment><USER10> What's wrong with FLV? I don't know much about it but as far as I know it's a decent container format, especially now that it can wrap H.264 and AAC.

<comment><USER9> The competing formats all originated with streaming video in mind, while flash backed into it.

Just watch a YouTube video compared to the same video streamed over the internet in almost any other format.</comment></comment></comment>


Mass Anomaly Detected Under the Moon's Largest Crater - <AUTHOR> https://www.baylor.edu/mediacommunications/news.php?action=story&story=210457 <comment><USER2> moon is a cheese hologram satalite alien base confrimed</comment>


The Horrible Place Between the Apps - <AUTHOR> https://www.nytimes.com/2019/07/04/style/how-to-quit-facebook-twitter-instagram.html <comment><USER2> Close your account and forget about the service. It worked for me, I closed Facebook in 2011 and haven't checked it since. It _may_ work for you.</comment>


Minimizing a sum of clipped convex functions - <AUTHOR> https://arxiv.org/abs/1910.12342v2 <comment><AUTHOR> Hi! One of the authors here.

We thought this paper might be of interest to people in data analysis or machine learning for fitting problems which have many outliers in data (in relatively simple ways). We a few examples where most common heuristics fail pretty badly, yet this approach does surprisingly well (see Section 6.1).

We also show an application in autonomous vehicle control for lane-changing and such, which may also be of interest to a slightly different crowd! :)

There is also an open source implementation, for those interested in using this package: [https://www.github.com/cvxgrp/sccf](https://www.github.com/cvxgrp/sccf)</comment>


Ask HN: Tips for Making MacOS High Sierra Faster? - <AUTHOR> I really like my 2010 Mac Book Pro 15'. Now I run MacOS High Sierra.
I am already using Vim for programming and terminal as much as possible.
I am also using Grayscale mode (and saw other people recommending it here https://news.ycombinator.com/item?id=17477760).
I am looking for more advices to make MacOS High Sierra faster. <comment><USER2> Run fast programs.

Skip Electron based shit like Slack, Spotify and the like.

Don't overload the system disk. Keep it at below 20% full.

Upgrade to a SSD if you don't have one already.

Bump up the RAM (there are aftermarket RAM options).

Grayscale mode wont do much. It will only affect the graphics pipeline, not actual speed of the program's you're using.

Disable most always on third party services and run them on demand (you know, programs that want to run in the background all the time, like third party updaters, clipboard services, and such). Can live some programs you find essential though.

Don't hack into Apple's settings for anything aside enabling/disabling "defaults write" like options. Don't go removing folders etc and following BS web advice from random tinkerers.

Best of all, why do you want to make "MacOS High Sierra faster"? It's fast enough as it is. On a 2016 MBP I edit 4K video, write music, program in IDEs and VMs, and so on.

Do you have a specific workflow you want to make faster?

</comment><comment><USER3> I know it's a bit unsolicited, buy you could give a linux distro a try. Usually works pretty well on those slightly older MBPs, I've done that a few times with a lot of success.

<comment><USER4> Well, OP specifically asked for faster MacOS, not a faster MacBook.</comment></comment>


The Art of Tidying Up - <AUTHOR> http://www.economist.com/blogs/prospero/2016/01/tidying-up <comment><USER2> I read Ms. Kondo's book out of curiosity about a month ago. If you're just looking for some new tidying ideas/tips, don't bother with the book - it's written in more of a self-help style that regurgitates the same simple points ad nauseum.

There are really only a few practical tips in the book:

\- Don't be afraid to do a big purge. Your stuff is just that, stuff.

\- Do the big purge all at once. "Ongoing" tidiness should simply be putting your stuff away, not constantly revisiting different parts of your home looking for stuff you can throw away.

\- Look up "konmari folding" on YouTube for a new idea about how to fold and store your clothes. For those who are already fairly tidy, this is the only real "new" idea in the book that may interest you.

\- Be affluent enough to have these problems in the first place. None of the advice is for people who are simply slobs, it's for people who have accumulated too much stuff and who feel it dragging down their life.

<comment><USER3> I enjoyed the book but agree that it was pretty pedantic and for lots of people that's overkill. That said, I think you missed the two points that I found most useful:

1\. When deciding what to keep/discard, keep things that "spark joy in your heart". That is, don't use rules like "If I haven't worn this in X".. The book's explanations around this are pretty helpful. 2\. Do the big purge in order of type-of-thing... not room by room. I think the specific order prescribed is something like Clothes, Books, Papers, [I forget, I forget], Keepsakes. Going by type makes it easier to make sound decisions, and the sequence of types warms you up for hard purges (keepsakes, etc) that will otherwise likely hang you up in room #1.

All of that said, I only really got through Clothes, books, and papers... but even just that was massively helpful.

</comment></comment><comment><USER4> I am all for tidying up. One should not forget though, that there are many reasons for why things end up the way they do (as in, cluttered and untidy). I don't think that it 'just happens' that your house fills itself with things that you never will use. Sure, we can blame consumer culture and capitalistic indoctrination. But if we're honest, most of the stuff that we buy is because we hope that it will change us as a person and that we can fill that emptiness that lingers inside.

In the end, buying will not change lives as much as we think. Change has to come from within and from connecting with others. I really doubt that "300,000 things" will achieve that change.

I think the authors of [http://www.theminimalists.com](http://www.theminimalists.com) have some great answers regarding the question "if not consumerism, what will add value to my life?". While most of you already know the answer "friends, health, passion, etc.", and are tired of the platitudes, I am sure that it is easy to forget the values in a world surrounded by messages of consumption. If you are interested, I would recommend starting with this article [http://www.theminimalists.com/21days/](http://www.theminimalists.com/21days/) about how the authors Joshua Fields Millburn & Ryan Nicodemus got started on their journey to minimalism.

<comment><USER5> I don't think anyone is suggesting that a home filling up with things `just happens' \--- most people will readily admit that they have bought or received those things, and that those things are there because of their own action (acquisition or receipt) or inaction (unwillingness/inability to dispose of items).

I also take issue with the implicit suggestion in your comment that most people genuinely think that consumerism will add value to their lives; I see that attitude a lot in `minimalist' blogs and discussions, and I realise that they're selling a narrative and a lifestyle, but it's very condescending.

People end up buying things to try and facilitate change or to bring happiness often because they don't know of any other method, or because other avenues have failed them, or they don't have access to them in the first place. When asked, most people will admit that a new gadget or purse or pair of shoes or a second helping of cake will bring them some kind of joy, perhaps fleeting, but will also admit that family and health and following their passions are more worthwhile goals. It's not either/or dichotomy that it's so often set out to be by `minimalists'.

In my own experience, I know and work with people for whom many of these things are impossible to follow for whatever reason. Some have abusive families and still deal with the fallout of that. Many have passions but simply don't have the money to follow them as much as they'd like, or at all. Some people have chronic health issues which they cannot overcome. I'm certainly not going to harangue them or judge them for buying another DVD, or another book, or another pair of cheap trainers because they can't follow more `worthwhile' paths.

Inversely, I've come across a lot of `minimalists' \--- mostly online, but some in real life --- who fetishise their _lack_ of possessions the same way many collectors fetishise their collections. Minimalism-as-less-stuff is just as informed by consumerism as maximalism-as-happiness is; it's simply the opposite side of the same coin.

<comment><USER6> In addition to what you say, there's nothing wrong with collecting things you're passionate about. Sure, value your relationships with family and friends, love the great outdoors if you must, but there's nothing wrong with also valuing your hobbies even if they involve collecting stuff.

Disclaimer: I am extremely untidy and also collect scale models and miniatures. My house is a mess, but that's a personality flaw (my kitchen is also very untidy, and that has to do with being a slob, not with the number of things I have in it). Of course, none of my stuff is "essential", but life is made up of nonessential things too.

I understand the criticism of mindless consumerism (for example, I couldn't be less interested in having the latest gadget, smartphone, etc, and I don't understand the people who are), but I really don't get the fetishism about not owning stuff.

</comment></comment></comment><comment><USER7> To give people an idea of what someone else found most interesting or novel in the book:

\-- The "spark of joy" test (hold the object in your hand and ask yourself, does this thing give me a spark of joy? if not, get rid of it)

\-- The consistent idea of respect for your things. This reminds me of older generations that more consistently mended clothing and fixed small home appliances. They understood that value of treating their possessions nicely (folding them well, storing them correctly) because it saved them time and money in later care. Many of us don't understand how to maintain our stuff -- we just get new socks when there's a little hole in the old one or wear the sock until the little hole is too big to fix. Kondo's book doesn't address fixing things, but it does address proper storage so that clothing lasts and performs better.

\-- Honestly, I love her folding methods and my sock and underwear space went from 2 drawers to 1. All my shirts now fit on one shelf as well. As someone who needs to see everything in order to process that totality, I was always accused of being messy before, because I'd rather keep all things things in view instead of in some stupid "storage solution." Now I can keep it all visible and look neat. Now how could I do this in my office?!

<comment><USER8> Most things are not worth taking care of due to planned obsolescence.

</comment></comment><comment><USER9> > This is fine as reference material, but casual readers may find themselves > wishing the author were as economical with words as she is with possessions.

</comment><comment><USER10> I have been hoping someone writes the digital equivalent of a 'tidying up' book. How to organize your files (or how to enable efficient searches), how to keep track of your digital possesions, whether to discard them or just store them on Amazon Glacier, proven strategies for storing logins & passwords, etc. Preferably written for techies.

We all have some sort of either adhoc or (rarely) a well-planned system of digital organization, but having a nicely written guide would be great for some things we haven't thought about (e.g., useful scripts, clever tricks, backup strategies, etc).

I've looked online for tips and tricks, but I haven't come up with much.

<comment><USER11> I'd be very interested in this type of book. I've been looking for some sort of community or forum discussion or even just the right term to google for ideas on better digital organization, and either I'm using the wrong term or the information isn't really out there.

I've even been tempted to read some books on library science to come up with ideas for organization, taxonomies, etc, but I haven't done it yet.

I have an idea for a small app that would help in sorting digital files easier (kind of like symlinks to a bunch of disparate folders based on context, with drag and drop support), just to make my own sorting process easier, but I haven't really sat down to work on it yet.

</comment></comment><comment><USER12> Rather than spending their time clearing out their rubbish I think most people would be better off learning to be more discerning about what they allow into their lives in the first place.

<comment><USER2> It's important to put her focus on getting rid of stuff into context: Ms. Kondo is a "tidying consultant" whose clients are mostly affluent people that can't even get started on tidying up in any meaningful way because they simply have more stuff than storage. She tells stories of people throwing out 20, 30, 50 bulging full-size garbage bags of excess stuff - these are people with a lot of money and a lot of accumulated clothes and possessions, and who live in homes large enough to contain it but not organize it. They are also affluent enough to be able to err on the side of getting rid of _too_ much stuff during an enthusiastic round of cleaning. Ms. Kondo exhorts her readers not to buy in bulk in order to avoid clutter - it's not like you need to be super-wealthy to pass up the cost benefits of buying in bulk, but her advice is not meant for people who are just scraping by or for whom the tradeoff of space-for-money makes sense.

<comment><USER13> I'm not sure why you've been greyed out. This is a fantastic point. This is by no means a book for every person. This is hardly even a book for every culture (though it's a huge best-seller in Japan).

</comment></comment></comment><comment><USER14> I think this book is about cultivating a home with exactly what you need, or essentialism; to view it as purely a self-help text on the aesthetic of minimalism is a loss to the reader, and overlooks the relationship between Zen and Japanese culture.

I was offered some advice last year by a monk who had been living at a monastery that resonated when I read this book:

"Our surroundings have a profound impact on our psyche. If you want to do good deeds, consider surrounding yourself with good people. If you want to work hard, consider surrounding yourself with hard workers.

And if you're feeling sad, down, and kind of messy? Clean your room."

<comment><USER15> "Our surroundings have a profound impact on our psyche."

Is this a proven fact?

Statements like these make sense intuitively but I would rather see scientific evidence for this statement than just accept it.

<comment><USER16> [http://www.bmj.com/content/327/7429/1459](http://www.bmj.com/content/327/7429/1459)

<comment><USER17> >Ethical approval Not required

</comment></comment></comment></comment><comment><USER18> > The average American home contains around 300,000 "things"

If I broke everything down into its components, that figure wouldn't even be close. In fact, I know of so few people who would come close, I'd question where this figure came from. I'm not in the US, btw.

<comment><USER19> > I'd struggle to get to 3,000.

I have that many books plus 500 CDs and 200 vinyl albums. My wife has a couple of hundred handbags and a similar number of coats and jackets.

But books are by far the largest class of thing in my house. I can't imagine having 300k items, even 30k seems rather unlikely in a house where you can see the floor!

Edit: I'm not in the US either so my house is probably smaller than the average US on though possibly larger than the other Brits commenting here; I'm in Norway.

<comment><USER20> A couple of hundred handbags, and a couple of hundred coats? How can you even store that many, let alone use them?

I know the classical exaggerations of these items, but I had no idea someone would actually gather such a collection.

<comment><USER19> Alright, I exaggerated about the coats, it just seems like hundreds, but the handbag count is literally true. Some of them are too decorative and fragile to use.

</comment></comment></comment></comment><comment><USER21> This book is very good for people who try to fill the hole in their hearts with shopping or having things. I don't think there's a huge match there to HN's audience.</comment>


The dystopian lake filled by the world's tech lust - <AUTHOR> http://www.bbc.com/future/story/20150402-the-worst-place-on-earth <comment><USER2> Previous discussion:

[https://news.ycombinator.com/item?id=9317003](https://news.ycombinator.com/item?id=9317003) (37 comments)

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>==

Other submissions with little or no discussion:

[https://news.ycombinator.com/item?id=10214167](https://news.ycombinator.com/item?id=10214167)

[https://news.ycombinator.com/item?id=10084484](https://news.ycombinator.com/item?id=10084484)

[https://news.ycombinator.com/item?id=9938481](https://news.ycombinator.com/item?id=9938481)

[https://news.ycombinator.com/item?id=9799272](https://news.ycombinator.com/item?id=9799272)

[https://news.ycombinator.com/item?id=9321591](https://news.ycombinator.com/item?id=9321591)

[https://news.ycombinator.com/item?id=9316025](https://news.ycombinator.com/item?id=9316025) (Oldest, at 230 days)</comment>


Modified ecstasy 'attacks blood cancers' - <AUTHOR> http://www.bbc.co.uk/news/health-14572284

<comment><USER2> Someone finally realized we can have our medicine and have fun too. One day we will not have to wade through three pages of possible side effects to get the treatment we need. Instead, it may have side benefits.

<comment><USER3> Do you really think that common recreational drugs have no side effects?

<comment><USER2> No, that's not what I was saying. I'm saying that the future of drugs should include positive side effects, benefits. Right now anything positive in a drug is considered recreational and avoided completely. Hence the perfect drug in this day and age eliminates disease but is otherwise completely neutral.

</comment></comment></comment><comment><USER4> Kind of strange that they only used the street name exclusively when referring to the drug.

It's MDMA, BBC.

<comment><USER5> It's the BBC. You have to speak appropriately for your audience.

Not to say the BBC's audience is a bunch of ecstasy addicts, but they aren't all chemistry PhD's either. Most people know drugs by their street name.

<comment><USER6> Although my daughter and her friends call it MDMA - ecstasy is what old people from the 20th century (like me) call it.

<comment><USER7> MDMA usually means in pure/cystal form, ecstasy usually in pills.

<comment><USER6> They talk about MDMA tablets though. I guess it's just each generation putting a stamp on it - like I would say "draw" instead of "pot"

</comment></comment></comment></comment></comment><comment><USER8> _The researchers, in collaboration with the University of Western Australia, have chemically re-engineered ecstasy by taking some atoms away and putting new ones in their place._

That sounds like a nod to Mitch Hedburg's line about fixing one of his jokes...

</comment><comment><USER9> I really would appreciate if they'd SHOW what those modifications look like.

Alternatively, link to the study(ies) and let me see for myself.

<comment><USER10> PubMed is your friend:

<http://www.ncbi.nlm.nih.gov/pubmed/21850491>

<comment><USER9> Thank you.

</comment></comment></comment><comment><USER11> How will the Daily Mail react: "Ecstasy Cures Cancer" headline seems unlikely.

<comment><USER12> WHAT WOULD DIANA THINK? BOFFINS ANNOUNCE NEW CANCER DRUG THAT CAN BE ABUSED BY RAVE YOBS!

<comment><USER11> "Asylum Seekers" will be involved somewhere.

</comment></comment></comment><comment><USER13> First line:

"Modified ecstasy could one day have a role to play in fighting some blood cancers, according to scientists."

Role. Haha.</comment>


Chrome Inspector Detector - <AUTHOR> http://adamschwartz.co/chrome-inspector-detector Detect whether the Chrome Inspector is open and docked, open and in a separate window, or closed. <comment><USER2> This ushers in a new era of annoying and pointless "This website prevents right clicks" popups.

Just the other day I said to my coworker everybody, by now, knew how to use firebug/inspector (he disagreed and, being in support, he does see more suffering than I do) - we were looking at a client site that had a _javascript obfuscation of the html source_.

It's like this grand battle stage of the worlds tiniest violins.

</comment><comment><USER3> A developer could use this to kill all the DOM nodes on the page when the console was opened. This might be the next generation of:

        img.onclick="javascript:function(){alert('Don\'t steal!');return false}"

<comment><USER4> but then we could just ensure that this line gets called first

      console.profile = console.profileEnd = function () {};

<comment><USER5> Not only that, you have to save a reference to the parts of the console that you want to use just in case they attempt to destroy those.

        var c = console
        var l = console.log
        var log = function(){ l.apply(c, arguments) }

Now they can't break the console from working with stuff like:

        console.log = function(){}

<comment><USER4> well in that case i guess you could always do

      var _console = console;
      console = undefined;

<comment><USER5> You may break something by breaking it yourself, like naive code: if (window.chrome) console.log("dev forgot to delete this"))

</comment></comment></comment></comment></comment><comment><USER6> How do I press ⌘ on Linux?

<comment><USER7> It's becoming increasing clear that on HN you're a second class citizen if you don't use Chrome on a Mac and develop on RoR.

<comment><USER8> I think you're confusing popularity with exclusion. Doesn't bother me or make me feel like an outsider because I use Opera as my primary browser and mostly Linux/Windows PCs. It's all a frame of mind and such statements are not really needed on HN because it's really not true.

I actually read the Rails articles quite a bit just because I like to not limit what I do or know to a small subset, even if I do not actively use it. Software does not come to other platforms unless one ports it, after all :)

Disclaimer: not a RoR developer, but I do use Python.

<comment><USER9> One of the main reasons I switched away from Opera was because so many neat little projects made with new HTML5 technologies would not work in Opera. This goes both for small side projects as well as business ventures.

I do understand the lack of support for Opera, with it having just a tiny market share in the US, but it still is a form of exclusion.

I'm glad Opera is switching to Webkit & V8 because besides the many websites breaking I found Opera to be much nicer to use than Chrome or Firefox.

<comment><USER8> Yeah, I'm kind of used to Opera not always working with everything that it does not phase me anymore after 10 years of use. If it's something I need to see Opera won't render, I either hack around it in Opera or just open Chromium. I also understand that Chrome is popular and many of the projects on hn are hacks put together for the developer and to show us what they do for fun and learning versus projects made for the masses, so I give leadway when things don't always work. Sometimes it's just a simple mistake and the developer is glad to fix it (like he did here [updated in the linked article] for anyone that did not have an Apple keyboard). Although we all have our favorites, most of us like to be accommodating if it does not require hours of additional personal time.

I have all the large browsers installed though for web development, so I can always open something else if needed. I just can't move away from Opera, because of all the native power features I would have to give up or find extensions that may or may not work exactly the same and have future support by their developers. I can say though that unlike some sites I frequented in the past (such as slashdot), I have never had anyone on HN make snarky remarks about me being an Opera user, which is refreshing and quite the opposite of being excluded.

I do think Webkit will help Opera in the long run as well, as long as they do not use it as a reason to throw away their long term commitment they have stuck with to keep backwards support for features and user interface elements. If they ditch most of that on the notion they can just tell users to use Chrome extensions, I would be truly sadden and have little reason to use Opera anymore. I'd probably end up forking Chromium in attempt to make it function like Opera once did and hope other former Opera users would help contribute via code commits along the way. That's just worst case thinking and I'm going to stay optimistic for now :)

Not to get too off track though from the discussion, but the OP (above my original reply) is correct in that there is quite a bit of RoR and Apple upvoted articles (if that was his point), but there are many others in a variety of topics. Perhaps not everyone is as interested as I am about broadening my knowledge of various technologies whether I use them or not, but I think many of us on HN are. Since I don't follow RoR or Apple news that much, I don't mind seeing it, because it at least keeps me exposed to information I don't follow actively on my own.

</comment></comment></comment></comment></comment><comment><USER10> Oh, the evil things I could do with this to coworkers who try to debug my Javascript code. Oh, the evil things I could do...

<comment><AUTHOR> It may not be clear, but the main use case for this app is not to harm someone, but to aid in development. Perhaps you're making a game and want to pause it or show wireframes when toggling the inspector. Or perhaps you're a designer and you want to show a grid layout whenever you're inspecting elements.

<comment><USER10> Or perhaps you want to make it so that when someone tries to inspect a DOM element, the element turns into a youtube video of Rick Astley singing "Never Gonna Give You Up." --Just sayin...

</comment></comment></comment><comment><AUTHOR> Thanks for reporting all of the issues.

I'll continue to improve and update [https://github.com/adamschwartz/chrome- inspector-detector/is...](https://github.com/adamschwartz/chrome-inspector- detector/issues) with the issues reported here. Thanks.

</comment><comment><USER11> Could be an intriguing way to detect other developers visiting the site and communicate with them. Last time I checked, the front page of <https://vimeo.com> was using the inspector console as a recruiting tool.

<comment><USER12> Great idea!

</comment></comment><comment><USER13> It's a nice demo and congratulation to Adam but I wonder if I m the only one that doesn't like that the browser allows this detection. I mean accessing the log is one thing but shouldn't this be this unreachable fro; the sandbox?

</comment><comment><USER14> Defeated:

        javascript:clearTimeout(setTimeout(function(){}, 1) - 1);

<comment><USER5> But what if he starts using setInterval? A more global solution is to: Open the "sources" panel, click on "Event Listener Breakpoints", then click "set Timer" and just delete the lines where it is calling the detector function.

<comment><USER15>
        chrome.inspector.detector=function(){return{}};

<comment><USER5> and what if he stops putting a public reference to the "detector" method?, read previous answer again.

<comment><USER16> Use Firefox.

</comment></comment></comment></comment></comment><comment><USER17> Doesn't work exclusively with the Chrome Inspector. Having the downloads bar at the bottom sets this off as well, for example.

<comment><USER18> Having a non-standard window zoom also sets this off.

<comment><AUTHOR> I've made the docked/undocked an experimental feature since it was causing the issues you were seeing. Please let me know if you're still seeing any issues with false positives for open.

<comment><USER19> From quickly checking the code before the reports, you seemed to be first checking for the height thing, and prematurely returning, before running any profiling. Wouldn't you avoid these problems if you first checked for the surer stuff, and then checked the height?

<comment><AUTHOR> @goldfeld absolutely. However, the profiler check mucks up the console output so I was hoping to use it as a fallback. For now I've made it experimental and will keep it that way until we can resolve the issues you pointed out. (<https://github.com/adamschwartz/chrome-inspector-detector/is...>)

</comment></comment></comment></comment></comment><comment><USER20> This is cool, I used the same technique in the discover- devtools.codeschool.com course for the first challenge.

<comment><AUTHOR> Yup! We credited <http://stackoverflow.com/a/15567735/131898> in the README ([https://github.com/adamschwartz/chrome-inspector- detector/bl...](https://github.com/adamschwartz/chrome-inspector- detector/blob/master/README.md)) which in turn credits you. :)

</comment></comment><comment><USER21> Works fine to detect the inspection window, but a false positive (as "open and docked") if I change Chrome window state from maximised to normal.

</comment><comment><USER22> On Windows, use F12 instead of Ctrl + Shift + I

</comment><comment><USER23> I was hoping it is doing kind of this detection [http://homakov.blogspot.com/2013/03/pwning-your-privacy- in-a...](http://homakov.blogspot.com/2013/03/pwning-your-privacy-in-all- browsers.html)

you simply used chrome api :)

</comment><comment><USER24> On Canary it continually spams this on the console:

      Profile 'Profile 13' started. chrome.inspector-detector.js:16
      Profile 'Profile 13' finished. chrome.inspector-detector.js:17
      Console was cleared

</comment><comment><USER25> Apologies if this is a silly question, but why is console.clear() needed for this to work?

EDIT: Oh, I get it, it must be housekeeping to clear the log messages generated by the profiler.

<comment><AUTHOR> Yup! :)

</comment></comment><comment><USER26> Worst case scenario, to defeat this: Save page to local drive, edit JS (and remove this) in your IDE/text editor. Open locally.

<comment><USER3> You'd have to open it with --disable-web-security to bypass potential CORS problems on some sites.

<comment><USER26> good point

</comment></comment></comment><comment><USER27> Interesting, I thought that you played with the document and window height

</comment><comment><USER28>
        delete window.chrome.inspector

Did I win?

</comment><comment><USER29> Doesn't work even without the downloads bar. ( Win 7 , Chrome Beta )

</comment><comment><USER30> Also doesn't work on ubuntu (at least not with scrotwm)

<comment><AUTHOR> Can you provide any other information?

</comment></comment><comment><USER31> Instructions are incompatible with Chrome OS.

</comment><comment><USER32> Great for easter eggs!

</comment><comment><USER33> Cases uses for this?

</comment><comment><USER28> $5 to the first Chrome extension that detects this and kills it.

</comment><comment><USER34> I don't get it?

<comment><AUTHOR> Perhaps you're making a javascript game and want to pause it or show wireframes when toggling the inspector. Things like that...

<comment><USER28> Good idea. You should package this as a Chrome extension then. No reason why I should run your code in my app, even in debug mode, when it can run outside and sandboxed.

</comment></comment></comment><comment><USER35> False. <http://i.imgur.com/7keR7aL.png> (Ubuntu 13.04, Plasma/KDE, KWin, Chrome 27.0.1448.0 dev. It says that no matter what I do...)

<comment><AUTHOR> I've made the docked/undocked an experimental feature since it was causing the issues you were seeing. Please let me know if you're still seeing any issues with false positives for open.

<comment><USER35> Looks okay now!

</comment></comment></comment><comment><USER5>
        console.profile = console.clear = function(){}

That's all you need write in the console to stop this annoyance.

<comment><AUTHOR> Does that make profiling unusable?

<comment><USER5> It does, but you usually don't want to profile other dev's pages; here is another solution that doesn't make profiling unusable:

        chrome.inspector.detector = function(){ return {open:false}}

But a more aggresive solution is this one:

        console = undefined;
        var iframe =     document.body.appendChild(document.createElement("iframe"));
        iframe.style.display = "none";
        window._console = iframe.contentWindow.console

And you can use `_console` instead of `console`

<comment><AUTHOR> It may not be clear, but the main use case for this app is not to harm someone, but to aid in development.

Perhaps you're making a game and want to pause it or show wireframes when toggling the inspector.

Or perhaps you're a designer and you want to show a grid layout whenever you're inspecting elements.

<comment><USER15> It would be nice to have DOM events (just like onResize), which would only be activated when activating the related option in the console (just like the "Show XHR requests" option).

[edit] <https://code.google.com/p/chromium/issues/detail?id=223418>

<comment><AUTHOR> Starred. Thanks for the submission. Would definitely be better to have this integrated into the browser.</comment></comment></comment></comment></comment></comment>


Your Nasty, Nerdy Sexism Isn't Cute - <AUTHOR> http://gizmodo.com/5935440/your-nasty-nerdy-sexism-isnt-cute

<comment><USER2> @Boboblong Trolls are normally depicted as males. Your argument has many counter examples Lovelace, Curie and Nightingale.

<comment><USER3> The same few women are always used as examples because there are only a few examples.

<comment><USER4> Programming has been 20-30% female since it stopped being 100% female (because there were six programmers). The compiler was invented by a woman. Just because you are too lazy and ignorant and sexist to notice that women exist as peers doesn't mean they don't.

You have no citations, just your own bigotry. Do us all a favor and shut up: the adults are having a conversation here.

<comment><USER3> I'm not talking about programmers. Learn to read.

</comment></comment></comment></comment><comment><USER3> Technology IS a male field, though. 99.9% of all technology was created by men, and not because of some conspiracy (i.e., The Patriarchy).

Whining, on the other hand, seems to be a female-dominated field. Women will be whining incessantly two days before the technological singularity transforms Earth into a utopia.

<comment><USER5> Oh _good grief_.

<comment><USER3> Hard to argue with that.</comment></comment></comment>