Discuss HN: Is it possible to grow ivory to stop poaching - <AUTHOR>

I'm a animal lover and this movie had me think about growing ivory (in a lab): https://www.youtube.com/watch?feature=player_embedded&v=rBbZOZr5Jtg
Does anyone know if it's possible or if someone is working on this? This should be a governement funded project.
My theory is to reduce the price of ivory, so that poaching would stop / decline.
People pay 100$ for small ones and up to 900$ for large ones (7-9 inch). Basicly something like 100 $ / inch.
Other estimates say it's worth up to 5000$ / kilogram (2.2 lbs). <comment><AUTHOR> Video : [https://www.youtube.com/watch?feature=player_embedded&v=rBbZ...](https://www.youtube.com/watch?feature=player_embedded&v=rBbZOZr5Jtg)

Price of ivory: [http://www.ask.com/question/how-much-is-ivory- worth](http://www.ask.com/question/how-much-is-ivory-worth)

Previous question about growing ivory from stem cells : [http://www.reddit.com/r/askscience/comments/1gnfam/can_stem_...](http://www.reddit.com/r/askscience/comments/1gnfam/can_stem_cells_be_used_to_grow_ivory/)</comment>


Adblock Plus filter lists may execute arbitrary code in web pages - <AUTHOR> https://armin.dev/blog/2019/04/adblock-plus-code-injection/ <comment><USER2> Good advice:

"Users may also switch to uBlock Origin.[1] It does not support the $rewrite filter option and it is not vulnerable to the described attack."

[1] [https://github.com/gorhill/uBlock](https://github.com/gorhill/uBlock)

<comment><USER3> There have been many good reasons to switch to uBlock Origin _long_ before today's issue: speed, memory footprint, no "acceptable ads", etc. I don't know why anyone still uses ABP.

<comment><USER4> It's mostly a marketing issue in my opinion. ABP was the first ad-blocker to enter the mainstream market back during the Firefox days, and they had virtually no competition for half a decade, before the entire Acceptable Ads controversy. I think unfortunately there is still a significant number of users who just associate "AdBlock == AdBlock Plus".

<comment><USER5> > a significant number of users who just associate "AdBlock == AdBlock Plus"

AdBlock uses Adblock Plus filtering engine internally and also supports and enables "Acceptable Ads" by default:

> AdBlock is a popular ad blocking extension for Chrome, Opera and Safari, now > based on the Adblock Plus code.[1]

* * *

[1] [https://github.com/betafish-inc/adblock- releases](https://github.com/betafish-inc/adblock-releases)

<comment><USER4> Oh, sorry, I was not referring to specifically that AdBlock extension. I wanted to say that users just associate "adblocking extension = AdBlock Plus".

<comment><USER5> Ah I see, never mind then; and in that case I do agree with your comment.

<comment><USER6> Any chance you're going to get the uBlock name back? Explaining the story every time I tell someone to switch to uBlock _Origin_ is annoying.

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> > Users may also switch to uBlock Origin. It does not support the $rewrite > filter option

Support for this filter option was discussed (and declined) in uBlock Origin's issue tracker: [https://github.com/uBlockOrigin/uBlock- issues/issues/46](https://github.com/uBlockOrigin/uBlock-issues/issues/46)

<comment><USER7> Damn, the developer of uBlock Origin recognized the problem with it immediately, explained it, and shut it down.

<comment><USER8> He is also the person who posted the parent comment :)

</comment></comment></comment><comment><USER9> It's a bit disingenuous to refer to this as an "exploit" all throughout the article. It's a feature, and an intended one at that. It's offering whitelist maintainers more power over their filters. You can disagree with its inclusion in the spec (as I do), but you should make an argument on that premise instead.

Calling it an exploit is no different than claiming .exe files are exploits because they allow arbitrary code to run. Or that browser extensions are exploits because they too can manipulate the page.

<comment><USER10> It's rightly referred to as a vulnerability; the term exploit is used to describe a realistic scenario that is enabled by the vulnerable code.

The problem is that you can't necessarily trust filter maintainers to be completely honest. Users don't regularly audit the thousands of rules in their filter lists, so a bad or compromised filter could easily introduce a malicious filter in an update. The $rewrite rule lets a filter change what code is being loaded by a webpage (under certain fairly realistic situations).

<comment><USER9> >The problem is that you can't necessarily trust filter maintainers to be completely honest.

I agree with that, and it's not a strong security model. But my original point is that the author is using a bad faith argument by describing a feature they dislike as an exploit. It's in spec for what the original authors intended. Just like running an executable program is potentially risky, but a design of the system.

<comment><USER11> > the author is using a bad faith argument by describing a feature they > dislike as an exploit

I read the article and perhaps it's been edited since you commented, but the author states in the introduction that there is a security vulnerability in a feature and provides an exploit. That to me is quite different from calling the feature itself an exploit.

> It's in spec for what the original authors intended. Just like running an > executable program is potentially risky, but a design of the system.

While it's true that it is in spec, I see a big difference in terms of how users experience this situation compared to running an executable program. I see this as more analogous to new feature introduced in an executable format that offers a different security guarantee to what users are already comfortable with. I don't see pointing this out as being in bad faith.

<comment><USER9> I don't believe it's been edited (or I haven't noticed such an edit). However on a subsequent re-read, I can see the author's usage of the term "exploit" is more specific to his example below (the Google Maps attack demo).

While I'd still argue it's "working as intended" (for better or worse), he is at least calling this specific demonstration an exploit rather than the feature as a whole. So I'll step back from that position, at least part way.

Thank you for the clarification on that point.

</comment></comment></comment></comment></comment><comment><USER12> I feel like this is another instance of "useful feature gets removed because of security vulturism[1]" \--- something which has been happening for a while, but has gotten infuriatingly frequent lately. In this case, the mere fact that you're using a third-party list already suggests trust of the author, or at least an implicit acknowledgement that your ideas of what should be filtered agree.

 _Ad blocking extensions should consider dropping support for the $rewrite filter option. It's always possible to abuse the feature to some degree, even if only images or style sheets are allowed to be redirected._

The classic "ban it because it can be abused" mindset. Let's ban the use of computers too, certainly that would be more secure!

 _Google has been notified about the exploit, but the report was closed as "Intended Behavior", since they consider the potential security issue to be present solely in the mentioned browser extensions._

As they should, because what user-agents are doing have nothing whatsoever to do with their site.

(Disclaimer: I don't use ABP nor uBlock nor any in-browser blocking extensions, so I have no conflicts of interest here. I use a full MITM proxy which is far more powerful than anything you can do with a browser extension. I wonder what he'll think about that...)

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

<comment><USER13> It could have been implemented in a more restrictive way to prevent this issue and allow more targeted behaviors, instead it allows third party lists (which already require a users trust) to run code. Previously this wasn't the case.

Can your MITM proxy modify HTTPS traffic? If so, how did you configure your machines to trust the cert you're using?

<comment><USER12> _Can your MITM proxy modify HTTPS traffic? If so, how did you configure your machines to trust the cert you 're using?_

Yes, of course. It wouldn't be very useful otherwise. The proxy has its own CA, and I install the cert into the trusted roots of all the machines I use.

</comment></comment></comment><comment><USER14> Making ad block filter lists Turing-complete: really bad idea.

</comment><comment><USER15> People are talking about uBlock Origin...

I really like it, no doubts it's good and everyone should consider using it.

BUT, since we are talking about uBlock Origin, I'd like to mention another awesome extention Raymond Hill made.

uMatrix ([https://github.com/gorhill/uMatrix](https://github.com/gorhill/uMatrix))

uMatrix alone is very powerful, and will prevent most ads.

Yes you as a user need to do the work, but the result is better.

If you like the idea of uMatrix, you may also look at NoScript!

Actually, I live almost ad free using NoScript + uBlock Origin for at least 2 yrs.

$rewrite... what a dumb feature btw!

<comment><USER16> I find uMatrix+uBO (with uMatrix set to block everything by default and uBlock Origin set to it's default easy mode) to be best setup. Ads virtually never get through, and most websites don't need javascript at all to read the articles so my uMatrix whitelist is actually surprisingly small.

</comment></comment><comment><USER17> Well the solution is easy: we just see which of the filterlist publishers are trustworthy and which aren't, and have the extension automatically download this listlist and apply it to its list of filterlists. Of course you need to be sure that the listlist is of trustworthy origin, but you can just check if the supplier of the listlist is itself on the listlist.

</comment><comment><USER18> More reasons to run Pihole, the setup just took 20 mins including installing Rasbian. Anyone know how to mimic ublock origins filter list in Pihole ?

<comment><USER19> Unlock can block page elements while pi hole can only block dns. So if the ad is served from the same domain as the site you are visiting, pi hole cannot do anything about it, but ublock can.

</comment></comment><comment><USER20> Some discussion by gorhill 11 months ago about this: [https://github.com/uBlockOrigin/uBlock- issues/issues/46#issu...](https://github.com/uBlockOrigin/uBlock- issues/issues/46#issuecomment-391303700)

</comment><comment><USER21> Switch to brave!

</comment><comment><USER22> one more reason not to use it... too bad the people using it won't ever read that (they should have switched years ago, so we know they don't read this kind of news)

</comment><comment><USER23> I wonder if we need a non-turning complete library for chrome extensions like we have for some packet filtering libraries and bitcoin script.

No regex.

No loops.

Constrained list of functions.

This could go a long way towards opening up the web to more extensions but also keeping it more secure.

I recently did a rev to the Polar chrome extension:

[https://chrome.google.com/webstore/detail/polar-pdf-web- and-...](https://chrome.google.com/webstore/detail/polar-pdf-web-and- documen/jkfdkjomocoaljglgddnmhcbolldcafd?hl=en)

and I had to request a new permission for filtering and they're now taking a WEEK to approve my any updates due to code review.

I really only need to evaluate a URL and add headers.

This doesn't need to be turing complete.

I basically just need to take a HTTP response and headers if they're missing when a specific origin is set.

<comment><USER24> This is where Safari content blocking extensions are now. The extensions register a list of URLs with Safari with instructions to block.</comment></comment>


The Hidden Cost of Touchscreens - <AUTHOR> https://medium.com/@caseorganic/why-do-we-keep-building-cars-with-touchscreens-alt-the-hidden-lives-of-touchscreens-55faf92799bf <comment><USER2> I sometimes feel I am in a minority of one these days.

Just about every car I've owned, I develop a muscle memory of where all the important switches are, and how far to turn to "hot enough" or "cool enough" etc. Same for most things around - I know fairly well how far to turn the oven for 180 +-10, no need to look. I might check if it's something especially sensitive (rare).

Thanks to iPhone (I have one, and like it) touch has become the answer to everything and that muscle memory doesn't work any more.

My current car is a pain in the arse as despite a dozen switches on the steering wheel they've forced simple functionality into the centre touch screen with awful UI where a simple switch would have worked fine.

Only Apple and a handful of others have any idea of usable UI - and even they aren't as hot as they once were. Anyone making appliances or cars is especially bad at UI. Worse if they decide to add helpful beeps. I don't want to be _looking_ at anything in the car except the idiots outside it and the speedo. Nothing. Ever. Give me the damn switches back!

Heck even smart phones are a step back for use as a camera or phone. Old Sony- Ericssons had the ergonomics of a camera as well, including button and lens cover. Every feature phone could be answered (and most of a text written) without looking even once.

I really would like my stuff to move beyond this cargo cult of touch and keep it just for the iPhone.

<comment><USER3> I still drive a 'dumb' car with actual buttons and knobs, because I loathe (with a passion) almost every car UI I have interacted with. I haven't been in a Tesla yet, but all the big makers (GM, Nissan, Audi, etc) get the interfaces so wrong, to the point where I assume it was their intention. I'd be interested to hear of any cars that get it right.

<comment><USER4> I really like the interface Mazda came up with. Right by the shifter there's a knob that controls everything on the screen, which is as easy to glance at as the speedometer. Muscle memory still works to an extent

<comment><USER5> They also keep the HVAC controls entirely separate, and there's controls on the steering wheel too, in addition to the "commander" knob and volume/mute knob.

</comment></comment></comment></comment><comment><USER6> This makes you appreciate the attention to detail, and the countless painfully learnt lessons, that goes into user interface design for airplanes.

Compare a Cessna 400's cockpit [1] to a switch cluster in a recent Mini [2]. The car still has physical switches, which is better than a touchscreen. It's also styled to resemble an airplane cockpit. But all the switches look the same, and some of them have two positions while others have three; some of them disable things while others turn them on.

In the Cessna, each control has a different color, and a different surface texture. The flap lever is styled to resemble an actual flap. The same goes for gear levers on planes with retractable landing gears: they are styled as little wheels. As the pilot, if you touch the wrong lever, you'll immediately feel the difference, avoiding dangerous mistakes.

In the Mini, all switches have the same color and they feel the same. Their status is indicated with a little LED on the switch itself. You neither feel the current status from touching the switch, nor is there any tactile feedback of whether you are touching the right switch. With a touchscreen, that remains true, but additionally the location of the switches changes too.

[1] [https://qph.ec.quoracdn.net/main- qimg-f37712d0cd771d5aee97ac...](https://qph.ec.quoracdn.net/main- qimg-f37712d0cd771d5aee97ac8dacd745b9-c)

[2] [https://www.gunaxin.com/wp- content/uploads/2017/10/2017-MINI...](https://www.gunaxin.com/wp- content/uploads/2017/10/2017-MINI-Countryman-Interior-5.jpg)

<comment><USER7> I don't think that's a lack of attention to detail from Mini. Just a decision made with the knowledge that people don't buy premium cars based on rational decisions. If they did, I'm not sure Mini (or BMW for that matter) would exist... I don't think this is the case for airplanes.

<comment><USER8> Are there any somewhat affordable cars that skimp on the "bling" to archive this sort of efficiency?

<comment><USER9> I'm happy with my 3rd generation Mazda3.

[http://images.nadaguides.com/ChromeImageGallery/Expanded/Whi...](http://images.nadaguides.com/ChromeImageGallery/Expanded/White/640/2018MAC170010_640/2018MAC170010_640_11.jpg)

The IVI display is out of the way but accessible (there's a jogdial on the center console to control it while driving). HVAC controls are manual and very easy to use without looking.

<comment><USER7> The problem is how to reconcile manual controls (which are great) with Carplay/AndroidAuto (which is even greater). The only control I have over Carplay without using the touchscreen is next/previous song and volume :(

<comment><USER9> The Mazda unit is supposed to be Carplay-enabled in the next couple of months. I'm curious as well to see what happens. I would hope the newer versions of CP allow for use of external control devices like the jogdial.

</comment></comment></comment></comment></comment></comment><comment><USER10> On my old car I could both read and write any value to the car without looking at the controls. That's important -- if I was feeling cold, but the temperature was set to where I wanted it, I'd turn on the seat warmer, as I knew I'd need to feel warmer only temporarily. Now I have to look at the controls all the damn time. One important thing was that all of the controls were asymmetric -- the buttons were all different sizes and positions, which looked awful if you were looking at it but YOU WEREN'T SUPPOSED TO BE LOOKING AT IT. It made it really easy to just reach out a hand and know where on the surface you were.

There's a reason that many professionals who use computers for repetitive high-skill tasks (video editing, music production) have custom input hardware for it.

<comment><USER11> Was it a SAAB? Pre-GM they had amazing cockpits, well laid-out and as easy to use at night as day.

<comment><USER12> I often wonder how much the environment the designers have to live in affect their designs.

With the nordics being very dark and cold for half a year or more, being able to operate the vehicle in limited visibility would be paramount.

Similarly, operating a capacitive touchscreen is not fun in -20C or colder.

</comment></comment></comment><comment><USER13> Touch screens and mixed user interfaces on things like cash machines, petrol pumps, etc kind of bother me - maybe later posts will go into this as the blog ends saying there will be a follow-up.

Just a couple of anecdotes - the first being cash machines where I input the PIN using the traditional buttons on the numeric pad, then i start using the touchscreen to make other choices. Pick one or the other, not a mixture of the two. Or self service petrol pumps that end up covered in grease and dirt, because they're in that kind of environment.

Once i was waiting in line at the Eurotunnel and the person in front of me was clearly struggling. It took them about five minutes to get through the registration process and they kept leaning over out of their car window, stabbing away at the touchscreen with their finger appearing somewhat frustrated. I assumed they must have had trouble finding their booking.

When I got to the booth myself I pressed the touchscreen and it was immediately clear that the calibration was off, by about a couple of finger widths - this was enough to cause the problems for the user before me, as they were trying to type in their booking reference but it would always choose the wrong digits. So when I typed in my booking reference I moved my finger a little to the side to account for the calibration error. Easy! Well, not so much if you're not technically inclined enough to recognise this kind of issue when you see it.

<comment><USER14> AFAIK, there's a special reason for the PIN pad: it encrypts the PIN, so the ATM doesn't have access to it. That's why even ATMs with touch screens still keep the PIN pad.

<comment><USER15> I thought it's just because it's way too easy to spy on the screen.

</comment></comment></comment><comment><USER16> > High contrast, color-coded buttons take less time to mentally digest.

I agree with this strongly and recommend using high-contrast features and color wherever it can assist in rapid recognition of important UI elements. I remember being surprised by how much font-lock-mode reduced my bug/typo rate; I started fixing many errors immediately after typing them because the color was obviously wrong.

However... it's important to remember that a _lot_ more color blind people will use your UI than you might suspect (if you even remembered to account for color blindness at all, which is unfortunately common). Color can still be used, but remember to _also_ include other no-color based differences and/or use a tool (or consultant) to verify everything is still high contrast and easily distinguishable.

edit:

> "and when this one becomes tolerable, they'll change the software on me."

I had an echocardiogram a few months ago, and the technician had to restart after making a minor mistake setting up the first image. Apparently the test equipment was modular, and the plug-in features would show up on the touchscreen UI _in the order the hardware was plugged in_. The medical center had two of these devices, and the technician was used to the other machine. The one we were using had several buttons in opposite locations. Obviously this was only a minor problem at the time, but medical equipment is another situation where it's probably a _very bad idea_ to make the UI layout unstable.

Having physical buttons has the advantage of limiting how much the UI can be changed in a software update.

<comment><USER17> Just a few days ago I added to my Pocket IMproved CSS style to 1) put some distance between the trash and other post icons and 2) colour-distinguish them.

[https://pastebin.com/raw/bdMw6jkr](https://pastebin.com/raw/bdMw6jkr)

</comment></comment><comment><USER18> I posted this comment 3 days ago on another article but it's just as relevant here. Touchscreens are great for people unfamiliar with an interface, but they seem to work poorly for experts.

\---

One place I lived had train ticket machines from the 90's that were an analog of Teletext. If you knew the 3-digit zone code for your end station, you could just jam in the zone code, adult, buy ticket, pop in your magstripe card and have a ticket in 5 seconds flat. It was absolutely perfect.

They were then replaced with user-friendly Windows-powered machines where buying the most basic ticket took 2 minutes as you had to poke though pages of stations on a crap resistive display.

</comment><comment><USER19> Would also potentially add "voice control" to this list. It's amazing to me that by trying to be "innovative/modern", most car user interface designs have become increasingly user unfriendly.

Case in point, the other day I spent 15 minutes trying to figure out how to connect my phone to a car via bluetooth (I'm still used to there just being a button for pairing).

Ended up having to search online for the instruction manual to figure it out, turns out pairing is only available via voice command when the car is in park ¯\\_(ツ)_/¯

<comment><USER20> _A loud clatter of gunk music flooded through the Heart of Gold cabin as Zaphod searched the sub-etha radio wavebands for news of himself. The machine was rather difficult to operate. For years radios had been operated by means of pressing buttons and turning dials; then as the technology became more sophisticated the controls were made touch-sensitive - you merely had to brush the panels with your fingers; now all you had to do was wave your hand in the general direction of the components and hope. It saved a lot of muscular expenditure of course, but meant that you had to sit infuriatingly still if you wanted to keep listening to the same programme_

Douglas Adams (1979) _The Hitchhiker 's Guide to the Galaxy_

</comment></comment><comment><USER21> This is exactly why I dislike the new MBP touch bar. I spend much of my working day in IntelliJ, debugging Scala code. I so badly want to rest my fingers on the function keys while I step in/out/over code, just as I used to in Visual Studio debugging C# and C++. I recently tried the native touch bar support in the Early Access version of IntelliJ and it was really not any better. It's no fault of Jetbrains either, I just don't care if I'm seeing a cute arrow icon instead of F9, as I don't want to have to look at anything at all, I want to rely on muscle memory.

Same goes for audio/DAW control surfaces; as much as I'd love to replace all equipment with an iPad, it just doesn't come close to the feel of an Ableton Push (for instance), and I don't see how it ever could.

<comment><USER22> Why did you buy it then? I think that all the marketing of "touchscreen: oooh shiny!" is working, and there is very little we can do about bad interfaces unless we vote with our feet.

<comment><USER23> Is there any other non Mac trackpad which just works. Once you use a Mac trackpad, its hard going back to something else.

<comment><USER4> Personally, no laptop I've ever owned had at trackpad that _didn't_ just work. Of course there were a handfull in the store at any given time that were mediocre, but that's why I try before I buy. The Mac trackpad is definitely great, don't get me wrong, but in my experience poor trackpads only appear on certain business models and cheap flimsy models. (Currently using a two or three year old Lenovo thinkpad yoga, the trackpad has always worked great)

</comment></comment></comment></comment><comment><USER24> The pinnacle of climate control is the 1988-1991 Toyota Corolla. The controls are obvious, they literally point to what they are doing, while providing tactile control and feedback. Everything increases in intensity as it moves to the right. The detents that a switch pass through allow the user to have full control while keeping their eyes on the road. All controls are independent (fan, AC, heat, recirculation). In the Volvo and VW there is literally no way to have the fan and not set the desired temperature, which will automatically control the AC or heater depending on the outside temp.

They then made the same regressions as the rest of the industry and moved to a display with modal buttons.

[https://imgur.com/a/nt0DwwP](https://imgur.com/a/nt0DwwP)

</comment><comment><USER25> >we never tested it on the road

That is an even bigger issue than the decision to use a touchscreen. Don't these companies want to make good products? I can't imagine releasing something without even attempting to put it through some realistic usage. Given the sorry state of in-car interfaces, I suppose I should not be surprised.

<comment><USER26> I worked at Microsoft on what would have been the next gen system after Ford SYNC and MyFord Touch. Our design team put a HUGE effort into making the UI usable at arms reach and at a glance. They had all this research about button sizes and how accurate a person could be with their outstretched arm. They built a full car simulator and we had modified cars in our parking garage we could actually test on.

Ford decided to go a different direction and I left the project shortly before it was ultimately scrapped. The ideas were awesome, but for various reasons, we never really built anything.

</comment></comment><comment><USER27> Seems like all the car manufactures are failing to learn all the lessons that Google and Apple have learned about touch screens and voice interfaces.

What's worse is whatever your phone of choice is, it's likely to know a HUGE amount more about your. Your contact list, what you searched on recently, tickets you bought, public transit research, etc. So instead of say "Navigate to Joe Random" you end up hunting and pecking at a terrible on screen keyboard with a terrible touch interface that doesn't even allow multitouch or swipes. God forbid you change your mind underway.

Distractions can cause lives, and car manufacturers are doing worse than Apple/Google. The easiest fix seems like it would be mandate that car manufacturers allows users to choose their navigation system.

More info on the distraction claims at: [https://www.prnewswire.com/news- releases/aaa-apple-and-googl...](https://www.prnewswire.com/news-releases/aaa- apple-and-google-speed-ahead-in-less-distracting-design-of-vehicle- infotainment-technology-300672764.html)

<comment><USER28> I have a patent on using morse code to text people on the phone rather than a keyboard. The idea is so you can text without looking at the phone.

A rocker switch is added to the edge of the phone, up is dit and down is dah.

I coulda been a billionaire! :-)

</comment></comment><comment><USER29> Agreee. Touch screens on cars are infuriating. You must look away to touch them and any movement might mean you accidentally touch other on sceeen buttons.

</comment><comment><USER30> Working in industrial automation I can confirm that ugly color coded touch interfaces are optimal. Group functions by color and/or menus by color. Operators quickly know where to glance for data and which "buttons" to press.

Most of today's UI's are centered around web/mobile where form over function is the rule.

</comment><comment><USER31> This makes me think of another field where bad UI decisions took years to undo... synthesizers! The rise of digital synthesizers in the late 1980s led to an elimination of knobs and sliders, in favor of buttons and menus. This made it very difficult to design your own sounds for them, as sound manipulation was no longer physically intuitive, and working with interacting parameters could mean a lot of menu-digging rather than just turning two knobs at once to find the sweet spot.

But it was cheaper. And there's where touch screens really come to the fore. They're less expensive than the bespoke hardware interfaces that cars otherwise use.

In cars, though, it's not enough to be hard to use. It's _dangerous_ to use the unfamiliar touchscreens while driving.

<comment><USER32> There has been a resurgence in analog and analog-style synths since the 80's but overall I think synth UX has gotten even worse with the rise of software synths.

Turning a virtual knob with a mouse pointer is a terrible UX. Mapping parameters to a midi keyboard is also pretty bad, with the exception of hardware like the Native Instruments S MK2 midi keyboards or the Maschine that are specifically built for controlling certain software.

<comment><USER31> And even then, midi mapping is a pain. There are a few synth makers who have figured out good touch-based iPad synths, but for the most part, ugh. Emulators! Try playing a Minimoog correctly on a touch screen....

</comment></comment></comment><comment><USER33> So how are touchscreens OK, but using smartphones while driving isn't OK? I mean, I got pulled over once for a little lane wandering while adjusting the radio. Which had knobs.

<comment><USER34> Playing the devil's advocate here... but it's easier to show advertisements if a screen is available ?

The skeptical side of me thinks that car manufacturers are simply preparing us slowly to accept screens in the car so that the next generation accepts it by default.

I recently switched to a car which is the outgoing generation of that particular model and (almost ironically) has a _physical button_ on the dashboard to simply stow the screen away. One cannot even tell that there could be a screen there !

There still is a screen in the instrument clsuter but it's monochromatic and I have set it up to display the speed and a "sub-readout screen ?" to display fuel consumption. The instrument cluster screen is also capable of showing GPS direction instructions as well if the main screen is stowed away.

Everything else has a physical switch. The HVAC status is dispayed on it's dedicated LCD on the center console.

 _I like the outdated tech in my "new" car._

<comment><USER35> > The skeptical side of me thinks that car manufacturers are simply preparing > us slowly to accept screens in the car so that the next generation accepts > it by default.

I'm not quite this cynical. I think car manufactures got all excited by the tech (in part due to Tesla just lazily slapping in a huge touchscreen and getting lots of coolness points for it, and in part due to the massive success of Android / iPhone / iPad), and decided they wanted cars to have that too. Car manufacturers are roughly 5 years behind current tech, so they rushed into touchscreens and by the time they got their products to market, the tech felt dated and the UX was never well thought out.

 _However_ , smarter car manufacturers learned from that and are now moving _away_ from the touchscreen-only controls now, using them just for auxiliary needs or for things that really require them (like GPS navigation).

Consider the the Gen 1 Volt, where _99% of all buttons are identical touch- only pads_. [http://hanabi.autoweek.com/sites/default/files/styles/gen-12...](http://hanabi.autoweek.com/sites/default/files/styles/gen-1200-675/public/2015-chevrolet- volt-012.jpg?itok=VmQ_3Qrl) As much as I love this car, this console is a huge UX disaster every bit as bad as a touchscreen-only car, and doesn't even earn any 'coolness' points for doing it.

Then in the Gen 2 Volt, they went _back_ and put in lots of distinct physical buttons and dials for those previously-touch-only actions [https://electromotivela.com/wp- content/uploads/2016/10/chevy...](https://electromotivela.com/wp- content/uploads/2016/10/chevy-volt-interior2.jpg) Not perfect, but this is a massive improvement over the prior model.

<comment><USER34> Some big mainstream brands such as Volvo and Audi have introduced touch screen based UX. You need to use the screen even to operate HVAC. Range Rover Velar even has a touch screen _in the steering wheel_ which changes according to the context.

But I do hope the manufacturers do realise that having touch screens only is incorrect and physical controls which can be operated by muscle memory are safer.

</comment></comment></comment></comment><comment><USER36> I still miss a physical button on my phone to take a picture. Haven't had it since my Nokia Windows Phone.

<comment><USER37> I don't get how jog dials aren't more popular for every interface. [https://en.wikipedia.org/wiki/Jog_dial](https://en.wikipedia.org/wiki/Jog_dial)

There is a 5 direction one from Sony. One or two of these and a small black and white screen near the gauges should be all you'd ever need.

<comment><USER38> Small jog dials are pretty bad. They require enough precision to force mistakes, while not giving actual precise input.

Might as well swipe the touchscreen (or a touchpad) with some haptic feedback.

At small sizes, well shaped buttons with all chosen stiffness and press depth are unbeatable. Not even a lever comes close. (think gamepads and analog sticks or hat controllers)

For analog input, levers are best, but they have to be big enough (joystick) though steering wheel comes close.

There is a good reason most vehicles use either a steering wheel, potentially multiaxis, or a joystick, augmented with buttons and levers. Stepped knobs are also good.

</comment></comment></comment><comment><USER39> This is why I will never own a Tesla Model 3. If I can't adjust the air conditioning while looking at the road, I don't want it.

<comment><USER40> You can set auto-climate control and will be able to change climate with voice in the future: [https://twitter.com/elonmusk/status/952750646406426624?s=21](https://twitter.com/elonmusk/status/952750646406426624?s=21)

<comment><USER41> They're solving a problem they introduced themselves eh?

Voice command: shout at car to make it cooler. Car doesn't understand. Shout at car to turn off radio so your voice command is clearer. Car doesn't understand. Take eyes off road to turn off the damn radio with the touch screen. Crash!

The button interfaces actually work 100% of the time. Voice command... lol...

<comment><USER42> It's fine because you can just turn on the Autopilot while you adjust the radio and everything will be fine.

<comment><USER43> Tesla created an interface that can only be used while driving by handing control over to software that is unable to recognize when a vehicle in front of you is at a dead stop.

And everything is just fine?

<comment><USER44> I think the parent comment was intended to be facetious.

</comment></comment></comment></comment></comment></comment><comment><USER45> > "The quality of the touchscreen is my fault", he admitted, "we never tested > it on the road". Apparently the management was so convinced that the > entertainment system's blue-tinted, rectangular touchscreen interface was > "the future" that the company didn't even bother using it on the road before > releasing it. After all, Tesla had recently debuted (to much acclaim), its > first model which boasted a similar touchscreen system. Now that this new > company's own car was in mass production, it would take many years to undo > the damage.

So management (of the car company) pushes through a choice they don't understand, without understanding the implications ... and the problem is touchscreens ?

Sorry. That's not correct.

Tesla's interface has a good cpu and is quite usable (knowing EU car manufacturers my bet is that the first problem is woefully underpowered cpu). I wouldn't say it's at peak performance yet, but it's certainly as usable as a first stab at lots of buttons would be.

This is in fact the entire premise of the entire article. Management blindly doing things because "they're the future" ... sucks.

But we all know what the real problem is as well. The opposite attitude in management ("stay with the classics") also doesn't work.

You NEED management to know the business.

No exceptions !

This is yet one more example of total management failure. It should not reflect badly on any particular interface design principle.

</comment><comment><USER46> Video games do this the best: you want a game pad like controller on the steering wheel with a HUD projected on the windshield.

You get the best of both worlds, a context-aware interface without losing focus on what's in front of you.

</comment><comment><USER47> Hahahahahahaha. Cars have some of the worst designed human interfaces known to man. In fact, virtually no designer of products (physical or virtual) cares anymore for their UX. It's sad, but in the mad rush to produce more and more, we've forgotten how to improve what we already have.

</comment><comment><USER48> My frustration with automotive controls isn't limited to touch screens, but I've never used a touchscreen I like. I have two cars with awesome controls - a 2000 camary and a 20007 suburban. Both have 3 knobs: 1) how hot/cold 2) how fast is the fan blowing 3) where does it blow. The radio has two nobs - "what channel" and "how loud". My wife's 2013 (?) "luxury" car is quite the opposite. All controls are either 1) buttons you have to press or 2) something on the touchscreen. The user interfaces force you to take your attention from the road to use. That is bad and _dangerous_ design ... end of story. I know the world likes to complain about using phones while driving, the the controls on some cars are just as bad.

</comment><comment><USER49> The latest fad in luxury cars are switches that are actually touchscreens that look like physical switches, sometimes complete with haptic feedback.

Let the sheer stupidity of that sink in for a while...

Meanwhile in my old Mitsubishi switches rarely break, and if they do it'll cost a couple of dollar to replace it.

</comment><comment><USER12> I think one reason store chains etc are moving to touch screns is that they can push various changes centrally.

I recall seeing older systems that used transparent keycaps, and invariably they would be covered in stickers and whiteout as the employees had tried their best to implement changes on the fly.

And now that i think about it, were there not a story posted a while back about a restaurant where the waiters used an age old grease marker on the screen of their POS to mark reservations that had arrived? This because while the software had such a feature, it required too many clicks or some such to be effectively done during a busy day.

</comment><comment><USER50> Related (from 2011): [http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesi...](http://worrydream.com/ABriefRantOnTheFutureOfInteractionDesign/)

<comment><USER51> I'd also recommend "Magic Ink: Information Software And The Graphical Interface": [http://worrydream.com/#!/MagicInk](http://worrydream.com/#!/MagicInk)

</comment></comment><comment><USER52> Having driven with the Tesla touchscreen, I can tell you you don't need to use it much while driving. The dials in the steering wheel can adjust the temperature, voice control is great for navigation and for selecting music, and range, performance data is on the dashboard (for non model 3).

If you need to do something complex like select a destionarion on the map, I don't think there's any interface that would let you do that safely as you need to visually identify a location.

<comment><USER53> I have a car with voice control and it's terrible for navigation with my 4 year old in the back seat. Seems it can't understand the phrase, "Drive to home why are you saying that daddy what did you say are you talking to the car daddy why?"

</comment></comment><comment><USER54> I'll take this opportunity to complain about my 2017 Honda HR-V. It has all of the problems described in the above piece.

It's the most dissatisfying thing about my car. In fact, it might be the _only_ dissatisfying thing about the car, and yet it's still enough to make me reluctant to recommend the car to a friend!

</comment><comment><USER55> A good mix of both touchscreens and physical mobs and buttons seems preferable. Similar to how the Apple Watch is designed.

</comment><comment><USER56> In the '90's, I worked as a software/systems engineer "upgrading" factory process lines (think 100 year-old paper mills, plasctic bottle processing, pharma) from big old buttons and knobs to industrial touch screens. It was a Disaster! Things that operators used to do in a few twists and pushes now required toggling between multiple screens. Small on-screen touch buttons that were the perfect size for computer nerd fingers were way too small for the big meaty fingers of the operators. Conveyor speed feedback that looked steady on an analog meter now looked unstable on a digital display with three decimal places of (un-needed) precision. I should do consulting for these car companies. I could tell them that a volume control should always be a physical manual device. :-)

</comment><comment><USER57> A coworker of mine often refers to his time of working on a CT scanner which this reminded me of. One story was around how a new model was released that used a touchscreen instead of tactile buttons.

As you can imagine, a doctor could previously fully focus on the patient as they were able to feel the feedback of physical buttons.

With the introduction of a touchscreen, they would have to continually switch between looking at the positioning of the patient, and looking to their right at the LCD panel in the CT scanner itself.

A quick look at the website of the large company in question seems to indicate that they reverted back to a non-touch screen display. I should hope so given that we're talking about hospital patients here!

<comment><USER12> Read about similar where doctors would keep using older DOS based software because they could operate the keyboard by touch, and thus bring up test results etc while maintaining the conversation with the patient.

</comment></comment><comment><USER58> The new interfaces out of Garmin avionics are all touch screen based. They did wise up and add a knob and reference bumps around the screen. Still, scary to think I'd be looking at a screen when landing a plane outside of IFR flights.

<comment><USER59> Also, touch screens are much harder to use in turbulence.

</comment></comment><comment><USER60> Every screen I guess is a touch screen in some regards, say pointer-n-clik screen. Many such screens are so overcrowded these days, that you are playing a game of "Kill this pop up" to consume original content.

Browser notifications, Newsletter, Follow on Social, Special offers, etc etc

Regarding touch screen mentioned in this piece, the problem is those who created the product never use it and never it in original usage conditions. Many ATMS machines are filled with alighment problems to over confusing options.

Even their MENU & Navigation is not thought through

</comment><comment><USER24> The Boeing Starliner has a similar problems with its "glass". It seems wrong on so many levels.

* requires sight (both line of sight and focus)

* fine motor control

* how does it interact with liquids (grease, blood, coolant, vomit) ?

* single point of failure (touch controller)

[https://www.google.com/search?q=boeing+starliner+touch+displ...](https://www.google.com/search?q=boeing+starliner+touch+display&tbm=isch)

</comment><comment><USER61> I love the many buttons of my old Volvo dashboard. Rotary ones to set up temperature, etc.

[https://upload.wikimedia.org/wikipedia/commons/6/62/Volvo_S8...](https://upload.wikimedia.org/wikipedia/commons/6/62/Volvo_S80_2.4T_2002_Blue%2C_interior_dashboard.jpg)

</comment><comment><USER62> It doesn't have to be a touchscreen. I drove my brother-in-law's porsche suv when it came out. It had physical buttons with a screen. You had to press through deep menus to do anything. I've used computers for decades and I couldn't figure out how to turn the radio off. I gave up and turned the volume to zero.

</comment><comment> m-p-3 IMO this is a cost that many popular smartwatches seems to forget these days.

Buttons are great for quickly interacting with the device without having to glance at it.

I shouldn't have to watch my screen to skip/pause a song, dismiss a notification, etc.

<comment><USER63> The Garmin Fenix 5X uses buttons rather than a touchscreen for interaction, and it _should_ be awesome as a result. Unfortunately the interface is so damn slow to respond that you end up having to look at the watch when navigating or using functions anyway. Also the feel of the buttons is spongey - there's no satisfying click to tell you when the button has been pressed properly. Again, a factor that forces you to look at the screen.

Not recommended: expensive, somewhat ugly, painfully slow UI, and frankly not that awesome in any way other than a relatively impressive battery life (unless you're using GPS!).

</comment></comment><comment><USER64> UI latency is also a huge related issue.

</comment><comment><USER65> tactile interfaces will be a future trend.

</comment><comment> orbital-decay On the other hand, many MFDs in recent plane cockpits, including military ones, were replaced or at least augmented with touch screens. That's probably not just a fashionable trend, since the avionics and particularily instrument displays are subject to much higher scrutiny than car entertainment systems, and must work and be accessible in much harsher conditions.

That said, I'd love to see some serious research on this topic.

<comment><USER66> I am learning to fly and know a fair few in aviation, most pilots actually detest touchscreen and much prefer physical controls that are tactile and gives _hard-realtime_ feedback.

If you have payed attention to the controls in a cockpit, you will see that all the switches, knobs, and levers have different sizes, shapes, texture, and tilt. That is not accidental. It helps with muscle memory and when you have to alter many many different parameters in a short span of time, knowing where to look for and getting "instant" and tactile feedback is important, that is hardly possible with touchscreen interfaces as I know them.

<comment><USER28> I love that the landing gear levers have little tires on the top. It's perfect tactile feedback.

The flap controls have little airfoils on the top.

The cockpit is full of things like that, all learned the hard way. People are very bad at inventing intuitive interfaces.

For example, aviation has standard phrases for things. Like "takeoff power" is maximum power, as that's what you use for takeoff. One day, a pilot was landing and suddenly had to abort. He yelled "takeoff power" to the copilot, who heard "take off power", and chopped power to the engines at the worst possible moment, and they crashed.

The phrase was changed to "full power".

How could a generation of pilots and aviation experts never notice the ambiguity inherent in "takeoff power"? But they didn't, until there was an accident.

<comment><USER25> An ambiguous use of the phrase "take off" was a key cause of the Tenerife Airport Disaster.

>As a consequence of the accident, sweeping changes were made to international airline regulations and to aircraft. Aviation authorities around the world introduced requirements for standard phrases and a greater emphasis on English as a common working language.[13]

>Air traffic instruction should not be acknowledged solely with a colloquial phrase such as "OK" or even "Roger" (which simply means the last transmission was received[58]), but with a readback of the key parts of the instruction, to show mutual understanding. The phrase "take off" is now spoken only when the actual takeoff clearance is given or when cancelling that same clearance (i.e. "cleared for take-off" or "cancel take-off clearance"). Up until that point, aircrew and controllers should use the phrase "departure" in its place, e.g. "ready for departure". Additionally, an ATC clearance given to an aircraft already lined-up on the runway must be prefixed with the instruction "hold position".[59]

[https://en.m.wikipedia.org/wiki/Tenerife_airport_disaster](https://en.m.wikipedia.org/wiki/Tenerife_airport_disaster)

[https://web.archive.org/web/20170218144312/http://lessonslea...](https://web.archive.org/web/20170218144312/http://lessonslearned.faa.gov/ll_main.cfm?TabID=3&LLID=52&LLTypeID=2)

<comment><USER28> My source for the anecdote was my father, who was a jet pilot for the Air Force, and spent some duty as an accident investigator. I wouldn't be surprised if the AF and civil aviation both had to learn that lesson the hard way.</comment></comment></comment></comment></comment>


What's It Like Living in a City Without Uber or Lyft? Ask Vancouver. - <AUTHOR> https://slate.com/business/2019/02/uber-lyft-vancouver-no-ride-hail.html <comment><USER2> I imagine its a lot like living in a city with Uber or Lyft and not using them.

<comment><AUTHOR> I bet it is quite different than that actually. The presence of rideshare in a city has spill over effects. A couple of examples:

1\. The current death spiral of the subway system in NYC. A lack of riders has caused the MTA to reduce the frequency of trains, which in turn causes the system to be less desirable, which reduces the ridership (and revenue) further. While a lot of other factors are at play in NYC, a substitution to ridesharing is definitely a considerable factor.

2\. Recently, I attended a wedding in a small town that lacked Uber/Lyft (and even calling for a taxi was nearly impossible). The consequence was we made dramatically different decisions on where to go for the afterparty. Walkability took precedence over how cool the place was. In places without Uber/Lyft, people's drinking/driving habits shift -- which in turn shifts various aspects of the city/town.</comment></comment>


Cli.fan - <AUTHOR> https://cli.fan/posts/introduction/ <comment><USER2> Seems like the author would want more than one post on the site before promoting it. Right now it just highlights one tool.

<comment><USER3> Perhaps the author is trying to validate the idea and ensure people care about the content. Obviously I'd like to see more so I sub'ed to the RSS feed (kudos on including that btw).

</comment></comment><comment><USER4> Great rundown on exa, looking forward to the upcoming content. Thank you for sharing - cheers!

</comment><comment><USER5> I love the site design, it is so clean.

<comment><USER6> I think the blinking "cursor" in the header is a bit distracting.

<comment><USER7> would be great if it actually functioned like a search box...maybe as a upcoming feature?

</comment></comment></comment><comment><USER8> I like the topic, but it is just introduction and one post! Looks like it is too early to promote it!

If it is solely shared to validate the concept, a direct Ask HN would be more effective to collect feedback.

</comment><comment><USER9> Nothing much about CLI, just a random tool displaying a rainbow of colors missing/changing important ls flags, at least to me, -t, -h.

</comment><comment><USER7> Shouldn't it have been prefixed with _Show HN:_ and have the creator post the first message

</comment><comment><USER10> Love the design! This is the first light/dark theme switch I've actually liked. Great work!

</comment><comment><USER11> subscribed to RSS immediately.

</comment><comment><USER3> Good effort mate, keep up the good work.

</comment><comment><USER12> Is there a twitter "feed"?

</comment><comment><USER13> How's this better than [https://twitter.com/climagic](https://twitter.com/climagic)?

<comment><USER14> Classic HN comment. It's got it all: dismissive, terse, oddly confrontational. Bravo!

<comment><USER15> Classic HN reply. Astute. Clear. Polite. Objective. Bravo!</comment></comment></comment>


Ask HN: Telecommuting Abroad - <AUTHOR>

Hi HN!
I am a Canadian and I do web design for clients in Canada, the UK, and the United States, all remotely. I never meet clients in person. Since I can take my laptop anywhere, I want to explore the world!
I am hoping that the collective wisdom of HN has experience with visas in various countries. I'm leaning toward Europe. Germany, Spain, Czech Republic, maybe France. My work would still be for Canadian clients predominantly, and I'd like to be able to stay for more than the typical vacation limit.
Does anyone have any experience doing this?
Thank you HN! <comment><USER2> Philippines: Extend your visa for 16 months without having to do a visa run. Basically you extend every two months, which is generally a 20 minute or less visit to the nearest immigration office.

Don't know about Europe.</comment>


Like Electronic Music? You'll Love Mugasha - <AUTHOR> http://www.techcrunch.com/2009/08/20/like-electronic-music-youll-love-mugasha/

<comment><USER2> Great for zoning out and working. I've been using it so much lately that I've added it as a Fluid SSB menu item.

<http://fluidapp.com/>

<comment><USER3> That's actually a good idea. What would be better though is an "mini" version of the site with just the player controls and basic navigation functions. Would look super slick in the menu bar :)

Almost like digg in this case: <http://fluidapp.com/i/menuextra-digg.png>

<comment><AUTHOR> We are looking into Appcelerator Titanium to bring a more Native experience to the desktop. It's also cross platform.

<comment><USER3> Wow, never saw that before. Hope its not just another AIR clone :P

</comment></comment></comment></comment><comment><USER4> I'm totally blown away- great job!

The music is phenomenal, the design is beautiful, through and through it's just the perfect site to listen to while working. Badass!

</comment><comment><USER5> Congrats to you all! I've been enjoying Mugasha for a few months now, and have sent invites to several friends. Its been a hit with me and everyone I've shown it to.

</comment><comment><USER6> Congrats guys! I've enjoyed using it during the beta, it's a great service.

</comment><comment><USER7> I can't get anything on the site to play - it just sits there thinking when I click on a song. Overloaded?

Site looks great though. I'm excited to try it out!

<comment><USER8> Make sure you have flash enabled for the site.

</comment></comment><comment><USER9> The PsyTrance tag has only two members and I didn't even see a goa tag. Is that just because the site is new and there aren't enough taggers yet?

<comment><AUTHOR> Yea About 75% of the content is not tagged yet.

</comment></comment><comment><USER10> this is great, i'm a huge fan of electronic music--really good stuff to get creative with. also check out grooveshark and thesixtyone for discovering music.</comment>


Show HN: My company's holiday mini-game for charity (code in comments) - <AUTHOR> http://holiday2013.foraker.com/

<comment><AUTHOR> It was our first try with Meteor, which was fun. Code's here: [https://github.com/foraker/foraker-climb- meteor](https://github.com/foraker/foraker-climb-meteor)</comment>


Seth's Blog: Linear and parallel - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2009/03/linear-and-parallel.html <comment><USER2> I assume he means "serial and parallel".

</comment><comment><USER3> Will everyone just subscribe to Seth's feed and lets stop doing double duty?</comment>


Who's writing the book on web business? (1996) - <AUTHOR> http://www.fastcompany.com/27309/whos-writing-book-web-business <comment><AUTHOR> Specifically:

"You moved from New York to Seattle to start this business. Why?"

Bezos: "It sounds counterintuitive, but physical location is very important for the success of a virtual business. ... Obviously Seattle has a great programming culture. And it's close to Roseburg, Oregon, which has one of the biggest book warehouses in the world. We thought about the Bay Area, which is the single best source for technical talent. But it didn't pass the small- state test. I even investigated whether we could set up Amazon.com on an Indian reservation near San Francisco. This way we could have access to talent without all the tax consequences."

</comment><comment><USER2> "Amazon.com is not going to put bookstores out of business. Barnes & Noble is opening a new superstore every four days. Borders is opening a new superstore every nine days."

Well, that turned around pretty quickly. In 15 years Amazon went from "we aren't really competing with brick-and-mortar bookstores" to putting Borders out of business.

<comment><USER3> I guess even Bezos didn't realize they're disrupting them, since the book on disruption - Innovator's Dilemma - was written a few years later (although Peter Drucker's "Innovation and Entrepreneurship" book had roughly the same concepts in it, and was written decades earlier).

</comment></comment><comment><USER4> _Bill Gates laid it out in a magazine interview. He said, "I buy all my books at Amazon.com because I'm busy and it's convenient. They have a big selection, and they've been reliable." Those are three of our four core value propositions: convenience, selection, service. The only one he left out is price: we are the broadest discounters in the world in any product category. But maybe price isn't so important to Bill Gates._

Nice.

</comment><comment><USER5> "I even investigated whether we could set up Amazon.com on an Indian reservation near San Francisco. This way we could have access to talent without all the tax consequences. Unfortunately, the government thought of that first."

'Investigated' is a far cry from 'tried'

</comment><comment><USER6> Interesting how early on amazon had pegged personalized recommendations as a key differentiator between the physical and online spaces.

What amazes me is how even 15 years later this is something that a lot of online stores still do quite poorly.

<comment><USER7> I had a couple friends in tech group at Borders back in the late 90's. I paid a visit once, and had a guy show me a personalization/recommendation engine he'd built - in his spare time - which was pretty damn good. It was essentially a book 'locker' \- input all your book info - even stuff you didn't buy at borders.com - and it would give you better recommendations, news, etc.

Obviously could have been better, but he couldn't convince _anyone_ with any power at Borders that this was even remotely useful for the company. He'd seen this future and did a decent first pass of this in 1998/1999\. I believe he left soon after that, and we see what happened to Borders.

This really touches on the 'lifestyle business' article currently on the front page here, which had something like "sales and marketing are the #1 skill". The older I get, the more this hits home. Your idea can be brilliant, but if you can't sell people on it, you're never getting any traction.

</comment></comment><comment><USER8> you simply have to investigate their balance sheets, and you will know after a couple of hours that they already know form the very beginning how to avoid taxes, no matter in which country they are.</comment>


Chrome dev on WebGL security and Microsoft bullshit - <AUTHOR> http://games.greggman.com/game/webgl-security-and-microsoft-bullshit/ <comment><USER5> Passionate and unconvincing. You can't get around the fact that WebGL lets a website control the graphics driver in a way which is much too direct for comfort. The central problem is the poor quality of driver code compared to OS code. If these were of equal quality, then indeed this would be no more dangerous than a JVM. [EDIT: and for extra danger, the driver code generally runs at elevated privilege.] You can presumably exploit a hole in the OS by executing something in a JVM, but that's been an extremely rare exploit because of the high quality of the JVM and OS code in the relevant parts of their interface. This thing opens a huge attack surface against much more vulnerable code. Driver code is buggy, usually prematurely released in a rush to market, and deliberately closed and obscured. Maybe the answer is to make that code better across all the graphics companies, but until this happens, I fear WebGL.

The guy himself gives examples in which they have to work around known bugs which exploit vulnerabilities with formally valid inputs. But what about the unknown bugs? Those are the ones that will get us, no?

Now, I don't know if Flash 11 or Silverlight are just as bad. Maybe they are (although I see claims in this thread that this is not so for Silverlight). But this is not a good reason to support a hugely insecure technology. It's a reason to fear these other technologies as well.

<comment><USER6> I am not familiar with flash's api, can anyone point us to the docs in flash on how to access the shaders or a specific example?

<comment><USER7> The shader language is called AGAL, here is an intro: [http://blogs.adobe.com/flashplatform/2011/04/intro-to- adobe-...](http://blogs.adobe.com/flashplatform/2011/04/intro-to-adobe- graphics-assembly-language-agal.html)

<comment><USER8> Thanks, never heard of it. But why would they chose something so low-level that looks like assembly (reminds of the old shaders - I guess I have to read, maybe... easier translation for CPU if there is no GPU?).

<comment><USER9> Adobe also has a tool called Pixelbender 3D where you can write shaders in their flavor of HLSL. Its an extension to pixel bender (which was for 2D shaders only). Pixelbender 3D has to be used offline though, so if you want to embed shaders in a swf they have to be written in assembly. The reasoning for this is that the pixelbender shader compiler is larger than any single part of the flash runtime, so it would greatly bloat the flash runtime for a little bit of developer convenience. Adobe has done a poor job of showing that you can use high level shader code in their demos though, pixelbender will end up being the preferred way to author shaders for molehill, the assembly stuff will only be used by a few people for tests\quick hacks.

</comment></comment></comment></comment></comment><comment><USER10> I'm a fan of WebGL and I really hope it does gain traction, but I think people are being really irresponsible for ignoring what MS is saying (perhaps a bit of anti-MS mentality?). There ARE avenues for attacks through WebGL (e.g. [http://blog.mozilla.com/security/2011/06/16/webgl- graphics-m...](http://blog.mozilla.com/security/2011/06/16/webgl-graphics- memory-stealing-issue/)), you'd be crazy to ignore them.

Also, if Silverlight is susceptible to the same vulnerabilities, then that makes MS hypocritical, not wrong! And comparisons with Java and Flash getting hardware shaders is beside the point - MS doesn't have control over which features those products choose to include or not, they only have control over IE and Silverlight.

I hope a reasonable scenario develops where IE does get WebGL, perhaps a whitelist of drivers that adhere to higher degrees of security for use with WebGL.

<comment><USER11> It would be crazy to ignore MS on this point, yes. It would also be crazy, though, to take them at face value. While there are avenues for attacks via WebGL, I think it's clear that MS is being at least somewhat disingenous about the implications one can draw from the existence of such attacks. I am not enough of an expert to tell lies and facts apart in MS's statements, and so I cannot derive any real value from what they say. I am hence forced to derive my opinions on the matter from other, more trustworthy sources, such as the Mozilla blog that you linked to.

<comment><USER12> Mozilla and Google have their own agendas and biases around WebGL. If you want an independent opinion, look to security experts and low level graphics programmers who don't have a big stake in the browser vs native platform controversy.

<comment><USER13> You're going to find that security researchers are going to agree with Microsoft's take on this. People have been finding actual flaws in this stuff. Web browsers are the hardest piece of software we have to secure in 2011. Coupling them directly to video drivers is disquieting.

<comment><USER11> There's a big difference between saying that something is presently insecure and that it is by nature not securable. I understand and agree that WebGL is not presently secure at all, but Microsoft is making a set of claims far beyond this: that not only is WebGL insecure, it can never be made secure, and moreover, that Silverlight is somehow immune to the problems facing WebGL. That additional set of claims is why I say that MS is being disingenuous, if not outright lying. More than a good-intentioned warning about insecure software (which would be exceedingly ironic, given the source), MS's statement comes off as opportunism.

<comment><USER13> I see WebGL people saying essentially the same thing: that there is a reasonable degree of security that can only be assured by obtaining cooperation from driver vendors; that, in other words, the security of WebGL is not entirely under their control.

</comment></comment></comment></comment></comment></comment><comment><USER14> _"It's even more telling that Microsoft hired a firm, ContextIS, to create this bogus FUD so they'd have someone to hide behind. It's pretty convenient that only a few minutes after ContextIS's latest post Microsoft already had a well manicured response. If ContextIS had any credibility they'd be posting about the same issues on Silverlight5 (warning: might crash your machine), Flash 11 and Unity3D. "_

I always wondered about those IDC and Gartner predictions that WP7 will become #2 mobile OS by 2015, when it can't even get past 2% right now and its growth is slowing down. How did they get those numbers all of the sudden, when they couldn't even predict _half_ of Android's growth when Android was actually growing fast. So that seemed very fishy to me at the time.

If Microsoft is paying companies to do this kind of "publicity" that favors them, then I wouldn't be surprised if they are behind those so called predictions either.

<comment><USER15> Microsoft is known to hire other companies for such things, but they aren't really hiding it.

And I am sure that the ContextIS report is accurate and that WebGL represents a security risk, but TFA is also right - if WebGL is a security risk, than so are Silverlight 5 and Flash and Java applets, which are and will be everywhere anyway.

But because WebGL will get multiple competing implementations and everything is in public review, I'm also sure that it will be just better than the various other browser plugins that allow access to the GPU. The only problem with this picture would be IExplorer, since it has such awful upgrade cycles, that's why I'm kind of hoping they won't implement WebGL instead of coming up with something half-baked that ruins the experience for everybody.

I also couldn't care less about Gartner and IDC predictions: they never predicted anything worthwhile anyway. But WP7 will be popular. Maybe less than both Android and iOS, but popular nonetheless.

<comment><USER16> > but they aren't really hiding it.

That's not exactly true. I never saw a Microsoft press release clearly stating they funded a report they are referring to. They usually read like "$firm has published a study showing $product destined to dominate" or something like it.

</comment></comment></comment><comment><USER17> What a bunch of lies this is. Silverlight has nothing to do with XNA linked by the author. But even if we assume that SL5 uses XNA, XNA does not expose raw buffers in the code the way WebGL does and it does not allow one to write shaders on the mobile devices (one of the attack vectors mentioned in the MS article). SL itself does let you write PS (FS if you're from OGL crowd) and yes, this is an attack vector. But comparing this to WebGL is a false equivalence.

I find it amusing that even John Carmack (strong OGL supporter) agrees with MS on this one yet it is some random Google employee who gets his word spread. This author knows FUD very well, I give him that. He's proficient in spreading it.

<comment><USER18> > Silverlight has nothing to do with XNA linked by the author. But even if we > assume that SL5 uses XNA

I am not amazingly familiar with windows development, but "The core of the XNA Games Studio 4.0 graphics libraries is now included in Silverlight 5 Beta and is used to create 3D graphics. ", doesnt seem like a large assumption

> "John Carmack (strong OGL supporter) agrees with MS on this one yet it is > some random Google employee who gets his word spread"

I have a feeling the chrome developers have a better idea about how to sandbox a browser than John Carmack does, as awesome as he is, this is just arguing to authority when there is a long list of points that OP made that havent been refuted.

<comment><USER17> > doesnt seem like a large assumption

It is for the reason I've mentioned before: XNA abstracts out pretty much everything. With XNA you're not programming to the metal anymore, which is unfortunately true with WebGL. The greatest concern seems to be with the way OGL handles various buffers. For example in WebGL it is possible to create bufferData stating that it's of size X and provide Y values with Y much smaller than X. What you get is a buffer full of stale data from the memory. Bad idea.

Also there's much less "stuff" you can break in XNA with lower profile levels (feature sets) which are suitable for the web. E.g. you can't write shaders for the mobile devices today for both security and perf reasons. You get a preset amount of them and that's it. Yes, it's limiting, but you can't choke GPU to death and you can't submit shader payload that's known to crash given driver.

It's all about false equivalence that author makes in his blog entry. Problems exist with pretty much every piece of advanced software. But you can add small attack vector, or a large one. They are not equal and making it seem otherwise is bogus.

JS is amazing and I love 2D canvas. But WebGL is trying to put low-level stuff in the high-level code. It's awesome in terms of performance, but is inherently fragile and may be abused easily. It seems that it's not sensible programmers MS is afraid of but malicious attackers. And it's very unlikely that WebGL won't be happily abused.

As for Carmack, he stated at various occasions that he's closely following web graphics. He's also more than knowledgeable about the issues with drivers, how they can be hit even accidentally and how (un)likely it is for hardware vendor to fix them timely.

Also aside from the security, drawing from my experience, it is extremely difficult to make semi-advanced graphics code perform well and look acceptably similar on different GPUs. This is something APIs exposed in the high-level languages (which JS I think undeniably is) should hide from the developer, not dump on him. The fact that there are two different 3D canvas contexts - <USER2> and experimental-webgl - doesn't really help.

<comment><USER19> > The greatest concern seems to be with the way OGL handles various buffers. > For example in WebGL it is possible to create bufferData stating that it's > of size X and provide Y values with Y much smaller than X. What you get is a > buffer full of stale data from the memory. Bad idea.

Please at least check these things before asserting them. Assuming good will, I can see how it might be easy to assume that some things that are true in desktop opengl will be true in webgl, but both the linked blog post and the webgl spec explicitly state that all buffers are initialized upon creation, and all access calls are bounds checked. Tests of this are also part of the webgl conformance suite.

If you want to see where it is specified, see here: <http://www.khronos.org/registry/webgl/specs/latest/#4.1>

<comment><USER17> That is only partially correct. As mentioned before, there are two types of WebGL canvas contexts out there: webgl and experimental-webgl. Former does not put the GLX_ARB_create_context_robustness extension in place, which is basically what you're referring to.

</comment></comment></comment></comment></comment><comment><USER16> > Microsoft has never supported OpenGL

That's not exactly true. OpenGL support was introduced with Windows NT, IIRC. At that time, Microsoft found OpenGL support critical for NT to compete with the unix workstation segment.

They later started emphasizing Direct3D as the preferred way to do 3D, possibly because supporting OpenGL would make porting 3D-heavy games to other platforms easier.

<comment><USER20> Or, _possibly_ , because it's a better API and more developer-friendly environment.

Working at a low level with OpenGL is really painful, and there are no Direct3D-quality libraries on top of it to blunt that pain.

<comment><USER21> Do you have any comparisons or examples? I've found OpenGL to be a fairly straightforward API (if you ignore all the depreciated stuff)...

<comment><USER20> Just off the top of my head, because it's been a while since I rolled a list like this. One is a complaint from friends of mine that I haven't personally tripped over; others are my own issues from assorted hilarious Failures Of Graphics Programming.

* A total lack of typing. Everything is a GLuint. By the time I've bodged together sufficient type safety to be comfortable, it looks like DirectX.

* Extensions suck. Abjectly suck. While Direct3D has its problems, it does a pretty good job of saying "you must support these things". OpenGL attempts to vaguely say the same thing, but the difference is that Direct3D enforces support of things I want to use. It seems that you end up with many more code paths for OpenGL if you want to properly handle a lot of stuff.

* Difficult to query about GLSL problems, if possible at all. (An older example that's stuck with me is the noise() function, which nobody implemented the last time I dealt with this stuff. They returned a constant. Detecting this failure mode was nontrivial.)

* Tooling. As usual, Microsoft is way ahead in this area.

A project of mine uses OpenGL instead of D3D, but that's primarily because I'm not the graphics guy on that project. My own stuff just uses XNA, as it's 2D stuff I want to deploy to the 360.

</comment></comment></comment></comment><comment><AUTHOR> The author puts forward the (unsubstantiated) assertion that Microsoft paid context to search for WebGL security issues. Not that this is a bad thing (more eyes = better security long term) but it would have been good of Context to provide this information in their recent writeups.

</comment><comment><USER22> It's nice to see people this passionate. You could tell that he started off quite frustrated and slowly cooled down as he was writing, which I think always makes things more genuine/fun.

He's got me sold.

<comment><USER23> So emotion sways you rather than fact-based rationality, gotcha.

<comment><USER22> When it comes to arguments of logic, passion is a compelling and important emotion yes. However, the article was full of facts as well. Combined, it's pretty win.

</comment></comment></comment><comment><USER24> Two relevant links on the issue:

* DOS vulnerability in Silverlight 5s 3D (similar to WebGL DOS vulnerability) <http://news.ycombinator.com/item?id=2680001>

* Microsoft architect Avi Bar-Zeev: "Why Microsoft and Internet Explorer need WebGL (and vice-versa)" <http://news.ycombinator.com/item?id=2667332>

<comment><USER5> Avi Bar-Zeev says that the solution to WebGL security will be to ask the user to explicitly enable it per site (so it runs only on trusted sites), to sign shaders in the same way drivers and plugins are signed now, and maybe to maintain a whitelist of sites allowed to use shaders (or any WebGL at all). OK, that will work, but I don't feel that there is much chance of that happening. I still remember when JavaScript was a new-fangled untested technology, and IT departments would disable it by default on untrusted sites. Some people still surf only with scripts disabled. But really, there was immense pressure to give web apps a lot of the features of native apps, and everyone pressed ahead despite the security concerns, which ended up being very serious and costly. I suspect that the same thing will happen with WebGL - it will end up being on by default. The Khronos white paper on WebGL security is a very short and superficial dismissal of extremely complex issues, and Avi Bar-Zeev is being unrealistic about browser vendors being able to work around it all.

<comment><USER19> I don't believe that is what he is saying. He's saying that he thinks that extreme would still be worth it if that was required to run WebGL.

</comment></comment></comment><comment><USER25> First note:

"I work at Google on Chrome ... I was on Microsoft's side in the Java lawsuit, the Internet Explorer lawsuit and several others."

I would expect Google to get a demand notice _from Oracle_ to make the poster available for deposition in their suit :-)

Secondly, this bit:

"So imagine my disappointment when I start seeing the FUD from Microsoft about IE9 vs other browsers. Cherry picking benchmarks, cherry picking conformance tests and generally basically lying."

This has been a standard of tech marketing in some circles for so long, its astonishing that you are just now seeing it. From HP claiming memorex disk media would cause disk head erosion (these were flying heads) and invalidate your warranty, to Oracle lying about DB2 performance or the configurations, or storage vendors benchmarking on systems where they used thousands of disk drives so that none of them actually had to seek.

When there are only 'standards' Microsoft's browser team has to out execute other browser development teams. Market share declines suggest that this isn't a 'winning' strategy for them. When there are proprietary 'standards' for which other browser teams have incomplete information, browser dominance is assured. And as Microsoft is fond of saying, "Windows is 'open' because you get Windows based computers from any vendor."

Microsoft's goal is to make you look stupid, your goal should be to make what they think irrelevant. Complaining about their tactics just wastes time.

</comment><comment><USER26> From the article:

"[The GPU process] validates that the shaders submitted to the GPU use only the minimal features allowed by the spec. That means no dynamic indexing of sampler arrays. It means no infinite loops."

Halting problem solved. News at 11 :-)

<comment><USER27> > Halting problem solved. News at 11 :-)

Not necessarily, WebGL could simply restrict the shaders language to not be turing-complete. No need for solving the halting problem if you start from a total language.

<comment><USER19> yep. because webgl is designed to work on platforms that may have to fully unroll loops in shaders (because of its mobile baseline), webgl shaders are not turing complete in and of themselves.

</comment></comment></comment><comment><USER28> He has some good points and I like the description of safe-ish implementation of webgl in chrome. But I think the main point he misses with the Silverlight/Flash comparison is manageability from a security point of view. Running a plugin is different from using a feature in the browser - <USER3> often disable the plugins and are conscious about plugins being an attack surface so the admins often deploy policies disabling use of plugins.

<comment><USER29> Are you saying it's very hard to implement a checkbox to disable WebGL? A lot of browsers protect you from opening or resizing windows via Javascript. How could disabling WebGL be more complicated? My browser is even warning me when a Javascript is running slow.

<comment><USER30> I mostly agree, but there's a bit more to it than that. For example, you want to be able to report back to the page that WebGL is disabled, so that whatever content is supposed to be there can degrade semi-gracefully.

<comment><USER29> You mean something like:

      if(document.getElementById("canvas").getContext("webgl"))

;)

</comment></comment></comment></comment><comment><USER31> stopped reading at this line : "they might have a little more credibility if they weren't promoting a technology, Silverlight 5, that provides the EXACT SAME FEATURES with all the same issue"

first of all:

\- silverlight might be completley different division of microsoft company than IE. and have nothing in common.

\- i dont recall silverlight is included in IE either.

<comment><USER27> > \- silverlight might be completley different division of microsoft company > than IE. and have nothing in common.

Not relevant. Silverlight is shipped by the same company and provides the same capabilities with no significant differences/restrictions

> \- i dont recall silverlight is included in IE either.

Not relevant either, silverlight is shipped by Microsoft and some microsoft websites prompt for its installation, so Microsoft as a company does not seem to have much problem with Silverlight and its 3D capabilities.

<comment><USER31> read the related Ms article "WebGL considered harmful". there its stated that they wont include it in BROWSER beacause it is considered harmful. so silverlight is not include either. even if it is exactly the same as WebGL

<comment><USER32> But they were pointing out that what WebGL does would never pass their security reviews. This isn't even the IE team from my understanding but the security team at Mircosoft making this statement. I'm sure they work on multiple projects.

</comment></comment></comment></comment><comment><USER8> FYI: Chrome uses D3D to render OpenGL or Windows (AngleProject)

<comment><USER33> I believe that is only true for specific GPU/driver combinations with known problems in their OpenGL driver.

<comment><USER8> I think it's always using D3D on Windows. Take a look with depends.exe on

depends "C:\Users\<user- name>\AppData\Local\Google\Chrome\Application\14.0.797.0\libglesv2.dll"

It shows that D3D.DLL is used. There is simply no reason to complicate the life of QA and have two renderers.

Besides tracking down what works and what doesnt is very hard, and often depends on other things - drivers, settings, etc. (I have some experience with it, I work in gamedev company and we do port to PC regularly).

I myself like OpenGL much more than D3D, but my graphics peers think that D3D gives you more power to the metal. Now AngleProject is just trying not to be close to the metal, but to use what seems to work a bit more than OpenGL. (Although in honestly I haven't seen problem with desktop OpenGL on my Vista and XP machines - I have to use Maya, MotionBuilder and others and they do use OpenGL).

</comment></comment></comment><comment><USER34> How odd to cite his experiences internally at Google in a post not officially from Google. And to use "we" in his responses in the comments.

<comment><USER19> I see one "we" in his comments ("We're happy to accept the criticism when it is valid. This isn't."). I'm also not sure what experiences implementing webgl he's supposed to talk about except for his experiences at google. Making an argument based on actual implementation details is what you'd want here.

</comment></comment><comment><USER35> Mirror of text: [http://viewtext.org/article?url=http://games.greggman.com/ga...](http://viewtext.org/article?url=http://games.greggman.com/game/webgl- security-and-microsoft-bullshit/)

</comment><comment><USER36> I wonder how many Chrome developers develop in Win7 vs OSX.

<comment><USER37> A sizeable chunk of people on the team are developing Linux because of the build/link speed advantages. Some of us stick it out with Windows because we either like the UI better or because that's where most of our users are right now :-) I use Windows because I like the MSVS IDE the most, but only because for me it's the best of the worst. I really feel like we're pushing the envelope of how large a solution can be developed in it - with hundreds of vcprojs it takes a long time to load and de-jank itself. I wish Microsoft would use it themselves for things like Windows or Office, I would imagine it'd improve a lot if they ate their own dogfood.

<comment><USER38> > I would imagine [Visual Studio would] improve a lot if they ate their own > dogfood.

We do - just not VS :)

I used to work on Microsoft SQL Server. Our build system back then was substantially the same as Windows's. We used the Visual C++ command-line compiler, but we didn't use Visual Studio projects. Instead, our build utility was the BUILD.EXE program in the Windows driver development kit (<http://msdn.microsoft.com/library/ff542351>). BUILD is a wrapper for make that defines various useful macros, and enforces certain conventions for makefile contents (for example, the Sources file contains all and (mostly) only the source filenames to be compiled in the current directory). Our build environment wasn't the public DDK, but both have the same origin.

Relatively few people used Visual Studio, mainly because its C++ Intellisense was very slow (it took half an hour one time for the VS debugger to load a just-in-time crash dump). Instead, I used the Source Insight editor (a proprietary third-party product, but site-licensed by Microsoft), and used the WinDBG debugger from the public Debugging Tools for Windows. Source Insight is very fast at code browsing, fast enough for SQL Server's code base - <USER4> that is its main marketing bullet point. WinDBG isn't particularly fast, but it's no slouch either.

</comment></comment></comment><comment><USER39> Here, see MS security at stake here <https://github.com/mrdoob/three.js/> .

</comment><comment><USER40> He's not making his case when he essentially asserts it is OK because they've put in work arounds for a large list of known driver bugs.</comment>


Great Crime Decline:Drawing the right lessons from the fall in urban violence - <AUTHOR> https://www.newyorker.com/magazine/2018/02/12/the-great-crime-decline <comment><USER2> I don't know; it doesn't seem like he really answered the question: why did the crime wave start everywhere at the same time, and then stop everywhere at the same time? What did all those various places have in common?

<comment><USER3> You're absolutely right.

One actual theory is that the culprit was lead. [https://en.wikipedia.org/wiki/Lead- crime_hypothesis](https://en.wikipedia.org/wiki/Lead-crime_hypothesis)</comment></comment>


Show HN: Parcels – Package and Deliveries Tracker Built with React Native - <AUTHOR> https://itunes.apple.com/app/apple-store/id1229071393?pt=1235501&ct=show_hn&mt=8 <comment><AUTHOR> 3 months ago I was tired of incomplete tracking information I was getting with other apps for my packages from Aliexpress. I decided to build my own app, and learn React Native in the process. I launched with 10 carriers and thanks to CodePush rapidly added support for new carriers, without going through app review, saving immense amount of time.

Any feedback would be very appreciated!

<comment><USER2> I will have to compare to Parcel. I hate when it's unable to track certain packages!</comment></comment>


$5,000 will buy you access to another, new critical Java vulnerability - <AUTHOR> http://arstechnica.com/security/2013/01/5000-will-buy-you-access-to-another-new-critical-java-vulnerability/ <comment><USER2> I know Java is getting a bad rap. But isn't this really an issue with the Oracle JRE updates? And not just the JRE but updates to browser plugin.

I mention it, because Java is not just but a platform of many different tools. And there are many different implementations of the runtime.

E.g I am running icedtea plugin, I don't know if the same vulnerability exists but it is a different runtime implementation. And then our servers run IBM's jrockit</comment>


Tackling a 1B Member Social Network – Fast Search on a Large Graph - <AUTHOR> https://tech.evojam.com/2016/04/20/tackling-a-1-billion-member-social-network-fast-search-on-a-large-graph/ <comment><AUTHOR> An interesting case in handling huge graph data in a fast manner. Involves neo4j, elastic, Scala and other cool tech.

</comment><comment><USER2> Worth reading if you're into fast data and graph db real-life usage :)

</comment><comment><USER3> Nice article !</comment>


First-Mover Advantage Is About Compound Interest, Not Market Share - <AUTHOR> http://www.readwriteweb.com/readwritestart/2009/05/first-mover-advantage-about-compound-interest-not-market-share.php <comment><USER2> First-mover advantage is about network effects, not compound interest.

<comment><USER3> so are network effects a little like compound interest on marketing?

</comment></comment><comment><USER4> First mover advantage doesn't mean much unless there is a strong network effect at play...

<comment><USER5> I think the argument is that the point of first mover advantage is customer development more so than the network effect.

</comment></comment><comment><USER3> compound interest on knowledge. heh. I like it. it seems like it would especially apply when you were using a new technology; something for which you couldn't just pay money to get people with more experience.</comment>


Touch based WP7 programing environment and language by Microsoft Research - <AUTHOR> http://research.microsoft.com/en-us/projects/touchstudio/

<comment><USER2> It's nice that it has built-in touch and cloud support, and it's nice that you can code on-the-unit, using the touch interface. But it seems even less visual than existing visual languages (they are mostly academic/teaching experimnts; I don't mean "V"B - though its form creator comes close).

Could there be an entirely different approach to programming, built around the touch-screen from the ground up? Using its strengths (e.g. analog 2D input) and skipping its weaknesses (e.g. no digital symbols from keystrokes) - instead of trying to cram the old ideas into the new? Let it grow in its own way, I say.

A starting point might be visual form creation; lines for bindings, for transitions, for calls; multiple fingers for looping. Or, perhaps even better, to be like the _diagrams_ we sketch to represent coding ideas! Instead of adapting our most natural and intuitive expression (diagrams) to coding in text, why not work directly with diagrams, now that we finally have the appropriate tools?

Diagrams aren't suitable for all coding tasks, but I recommend fitting a technology to the tasks where it naturally excels.

 _disclaimer_ I haven't played with the tech (no WP7), just going by the webpage. Lest I offend with my ridiculously idealistic demands (who of us has created a fundamentally new approach to coding? Not I), this really shows that MS is pro-developer (while apple is pro-consumer) - and just _starting_ to use multi-touch as a programming fundamental is the most important step in this quest.

<comment><USER3> I am visual programming skeptic (or better said pragmatic). I've seen quite a few visual environments where at the end of the day (once you've learned the language) it was faster to switch to text mode. Visual programming was great for learning the language though.

The main problem visual programming encounters is the sheer number of options you have when you are entering code in text form.

Just consider that on almost any new line in code you can type in control structure, variable declaration, assignment, function/method call etc. And it is almost always faster to type "if" or "for" than to click through some decision tree to get to your required command.

In touchqode we try to overcome this limitation using prefix tree when showing code suggestions - e.g. when you have methods showTime(), showDate() and showLocation() you can type "s", press "tab" and you see longest common prefixes of methods starting "s" - so you would see "show". Then you can click it and see the actual method names.

Needless to say - templates for structured commands (e.g. "if") are probably necessary for programming on mobile devices.

I have few experimental features for touch programming in my mind, so I hope I'll get to implementing them sooner than later. If anyone has interesting ideas I'll be glad to discuss them.

<comment><USER2> I agree; yet I do think that there likely are a subset of coding tasks that are suitable for a visual approach (esp if a multi-touch screen gives other benefits, specific to that task). The only thing missing is knowing what those tasks are...

1) a way to address the choice explosion is (highly) domain specific languages, with limited choices. I guess this would be closer to scripting/macros than true programming, but still useful.

2) could the number of options be constrained in some other way? Or, perhaps chosen in a way that's more intuitive to touch - such as pointing to a graphical representation (of something that naturally has a graphical representation). OTOH, while good for nouns, less good for verbs. What about gestures for verbs (like sign language)? Maybe not for the specific choice, but to narrow it down to a family of choices?

3) and the bizarre idea of using the strength of multi-touch to make choices - like a chording keyboard (eg).

Is a keyboard really intrinsically better for coding than pen and paper? (maybe - there's linguistic power in symbols lacking in pictures).

BTW: A prefix tree is useful, but not specialized to multi-touch...

<comment><USER3> Just two ideas off the cuff:

\- have your methods and variables put into "categories". Then you could quickly choose category and you would be presented with limited choice in the category

\- code snippets - templated pieces of code (control structures, database access...) where you would just choose variables/methods to fill in the template

<comment><USER4> Good ideas. Basically, you want to make the language as high-level as possible.

Everything that can be generated or inferred from a high level description should be, for example using templates or snippets. Maybe the whole text based idea of programming needs to be side-tracked.

For example, represent the program as kind of (multilevel) graph. After all, graphs are easier to manipulate with a touch interface than text...

Interesting stuff.

</comment></comment></comment></comment></comment><comment><USER5> Might someone with a WP7 phone be kind enough to make a video of this? I'm super curious.

</comment><comment><USER3> It has some nice UI ideas - I particularly like the idea of calculator-like editor.

Environments with limited text input ability get significant advantage from staticaly (or at least strong) typed languages - code autocomplete is really killer weapon when editing text.

As a sidenote something similar can be achieved on Android phones using Touchqode [1] and Scripting Layer For Android [2]. It does not have specific language but you can use any of its supported languages - Python, Ruby, BeanShell (Java), Rhino (JavaScript)

Disclaimer: I work on touchqode

[1] <http://www.touchqode.com> [2] <http://code.google.com/p/android- scripting/>

</comment><comment><USER6> Duck Duck Go gets a bit of love in the sample applications. There is a sample app that talks to their API.

Interesting to see how they've shoehorned an editor into the touch screen interface. As an end user its nice to have a little more control over my device.

</comment><comment><USER7> The editing UI with the keywords as a calculator-style interface in the bottom half of the screen is an interesting '80s flashback. It reminds me of LucasArts-style adventure games with a grid of action verbs below the game view.

Also, those home computer keyboards where each key had both an alphabet and a BASIC keyword printed on it:

[http://ewyse.files.wordpress.com/2011/03/acornelectron_top.j...](http://ewyse.files.wordpress.com/2011/03/acornelectron_top.jpeg)

That was a pretty clever way to make the programming language quick reference available at a glance.

</comment><comment><USER8> This probably dates me and marks me as unhip but..

When I first read the headline, I thought "Why would anyone add a touch interface to WordPerfect 7?"

</comment><comment><USER9> First thought: Wow, the syntax looks like AppleScript.

Looks quite compelling though - hopefully they'll tie in the PIM and GPS features - imagine being able to ask you phone how long you spent physically at work during the week, or who are the top 5 people you emailed in the last month.

</comment><comment><USER10> it's probably not there yet: <http://www.ycombinator.com/rfs5.html></comment>


Bit.ly Button - jQuery Plugin for Your Clicky Post - <AUTHOR> http://www.moretechtips.net/2010/07/bitly-button-jquery-plugin-for-your.html

<comment><AUTHOR> bit.ly -The intelligent URL shortener- offers realtime statistics about the clicks on shortened links and this button takes advantage of that information. This jQuery button give you a uniform click count button -tall or wide- that people can also use it to retweet your post.

When you use a short link to tweet your post, it may get 100 retweets but in terms of bit.ly stats that could mean 1000 clicks coming from the whole twitter ecosystem which makes another interesting measure of how popular is your post!</comment>