Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is wonderful and beautiful. I don't want to knock it. I'll probably buy one and love it.

If you like this, also look at the demo video for Adobe's project Mighty/Napoleon, a pen and drafting tool combo that is pretty incredible: http://www.engadget.com/2013/09/17/adobe-xd-mighty-napoleon-...

What I think is sad about both of these products is that they are tied to specific apps. These closed ecosystems get to be more powerful instead of becoming tools on top of which larger things can be hacked together. I don't blame 53 or Adobe for that: making open hardware with open standard communication is probably incredibly hard, and getting it to interact with a tablet operating system through anything other than your one app is perhaps impossible.

But it's still sad.

With the growing popularity of hardware hacking, it's only natural that developers will start making our own physical tools the same way we write our own software tools. Unix makes this easy by providing abstractions like pipes, sockets, etc. for getting small programs to work together using common interfaces.

What are the OS-level abstractions that will make it easier to build, combine, and reuse our own hardware tools? The current methods for using device drivers, detecting wireless devices, or sharing them across a network are not very open to reuse and sharing.

What is the way forward where we can use something like this pencil with its smart palm rejection and erase, hack together our own physical drafting tool, and plug them both in to existing software by writing a little adapter?

It makes me wonder whether we need to go back and steal some of the bits of plan9/inferno: a single abstraction around sharing both data and devices, a natural way to multiplex input and output streams, and transparent network sharing of everything.



Pencil isn't designed to only work with Paper. Anyone who is interested in an SDK for Pencil should let us know what they are thinking about.

business AT fiftythree DOT com


Pencil isn't designed to only work with Paper. Anyone who is interested in an SDK for Pencil...

I can't help it, this makes me think of joke engineering documentation for everyday items.


I didn't realise it was a real product until near the end. I was thinking "Jeez guys, Penny Arcade did this joke four years ago!"

http://www.penny-arcade.com/comic/2009/3/9/


Wait, this is a real product?


I too was fooled by this line, I did a CTRL+F for iPad on the page and nothing came up so I thought it must be a joke... then I saw the apple app of the year logo and got confused...


> Pencil isn't designed to only work with Paper. Anyone who is interested in an SDK for Pencil should let us know

Tech quote of the freaking year.


Just document the protocol.

Unclench, already.


I hope Notability takes advantage of this. I'm a scientist and I use my iPad and Notability to take notes on research articles. I would love to use Pencil's features for this.

On a separate note, I can't believe the poor quality of apps available to scientists. Papers, the citation manager, can't run a release to save their lives, is expensive, and not impressive. I use it because it's better compared to the rest, but still not great software. Their iPad note taking is horrible compared to notability, so my PDFs are scattered between the two apps. It's a giant mess and waste of time I rather spend on research.


The new Mendeley iOS update is a vast improvement over their previous version. May be worth a look


I would love to see Windows Surface drivers so I could use this with Photoshop.


Surface already comes with Wacom's digitizer technology so you can get pressure sensitivity and all that good stuff. You probably just need to buy the stylus.


He may be talking about the RT models, which lack the digitizer of the Pro but still have the ability to run RT versions of apps like Sketchbook Pro


Sketchbook Pro is a desktop-only app; you are probably thinking of the metro version of Sketchbook Express.

Microsoft's own Fresh Paint app is another one that could benefit from this. One thing to note is that all of the Bluetooth styli released so far on iOS are exclusive to Apple's platform. An exception is Hex JaJa, which is cross-platform between iOS and Android, but it's not a Bluetooth stylus either - it utilises high-pitch sounds delivered via microphone.


They also lack Photoshop, though, correct?


Apparently there's an 'Express' RT version of Photoshop, might be what they're referring to?


Yes, I was simply saying it'd be nice to use this stylus on Windows with Photoshop because of its physical/aesthetic characteristics. It doesn't add much technically over the Wacom stylus, might even be slightly inferior, but it will feel different in the hand.


definitely inferior. No pressure sensitivity, which is odd because it does at least sense on/off pressure (to do palm rejection).


The obvious choice is procreate! I was a studiopaint die hard, now I only draw in my freetime (which is much better), and settled on mypaint a few years ago.

I don't own a tablet yet. But procreate, Paper, and the various stylus available are now very tempting.

I am just as happy now to watch the ipad market undertake the design market, as OS9 and NT did against IRIX. Watch us do more with more accessible consumer tech.


I wonder if the eraser could be used in more complex (if less elegant) apps such as AutoDesk Sketchbook or ProCreate to invoke a menu instead of erasing.


Wait -- you set up an entire system of metaphor, and then the most fundamentally associated of these doesn't work together? Even with the beautiful product videos to convince me of how well this skeuomorphism will complete me? I mean, not to be a naysayer, but you must have had interoperability in mind. Right?

(or is it actually truly an echo of an xkcd joke here?)


Napoleon is a really neat marriage of software and hardware. It's one of those rare things that's both new and familiar.

Mighty, meanwhile, he actually described as "cloud pen". Please stop. I need a great pen for a tablet. I don't need it dependent on your hosted services. It's driving me crazy how the cloud, an enabling technology, is being crammed down our throats as a feature in and of itself.


While it is not dependent on the cloud, it does leverage it to do things such as copy and paste between apps / tablets, and storage of assets for the pen.

(Disclosure, I work for Adobe).


That's full blown derp. Computers managed to do inter app copy and paste for how many decades before anyone though it would be sensible to send local data over the internet to another app on the same device?

The NSA wins again.


I agree on the apps part, but you're missing the "between tablets" part of this particular situation.


When you have poor APIs to work with you have to start thinking out of the box.


Quite literally outside the box, in fact.


But then the box never gets fixed.


That's a bit like saying that someone creating a web browser means it will never be as part of the OS.


>>What I think is sad about both of these products is that they are tied to specific apps. These closed ecosystems get to be more powerful instead of becoming tools on top of which larger things can be hacked together.

There are a number of high-end stylus makers that offer app developers SDK integration with their tools:

https://github.com/Adonit/JotTouchSDK http://www.tenonedesign.com/t1pogomanager.php http://www.hex3.co/pages/developers http://us.wacom.com/en/developerrelations/ios

And many drawing apps have taken advantage of them, such as the professional-level Procreate app, which allows one to use any of the pressure-sensitive styli listed above interchangeably.


I understand this, but it doesn't solve the problem. Imagine if someone said: "the developers of grep have come out with an SDK so that other text-oriented programs can integrate text matching!" The idea of grep-as-library is great, but it doesn't replace having pipes so that you can use grep with arbitrary programs, most of which have no idea they're being used with grep.

To build larger abstractions on top of these things, we need looser coupling. I want to draw and erase with Pencil, but use a manual dial to set the pressure because I do very precise architectural drawings. I want to draw with Pencil but use Mighty to make my lines snap to a grid and some other French Curve thing I hacked together with some dials for snapping to curves. I want to use two Pencils at once on two separate iPads and draw together with someone. I want my LeapMotion to understand my hand gestures to rotate data in an Excel pivot table and project it into a graph.

Yes, I want crazy things. But abstractions work to build crazy, unexpected text-oriented programs in Unix. So what are the abstractions we need to build arbitrary crazy programs with UIs and hardware peripherals?


Yes, this is like the old DOS days where e.g., your games had to be programmed with your specific make of sound card or you would have no sound (or PC speaker only). What we need is an OS-level API that allows apps to be mostly agnostic about what device is giving the input. And device manufacturers won't need to release app integration SDKs -- just code the OS driver.


And then we have windows all over again? I'm not sure that SDKs are that much better, but windows drivers have been the cause of many wasted hours...


Many OS's/PC's can even get laptop trackpads right, and we've been making those for over a decade: and shipping tens of millions. Apple gets it right, because they write their own drivers and OS.

I don't have high hopes for abstractions on pressure-sensitive styli.


I wouldn't assume that Adobe's Mighty will only work with Adobe apps. It is in Adobe's interest that it works with as many apps as possible.

You should expect to hear more around this when Mighty ships.

(Disclosure, I work for Adobe).


Ooh, truly good news. I will be very interested to see how it works on other apps in iOS.


"the FiftyThree team would like to release an SDK that would allow third-party developers to also take advantage of the device"

http://techcrunch.com/2013/11/19/fiftythree-pencil/


Great, but there needs to be a guarantee that you are free to develop any kind of application, even a competitor to Paper.


Why would you even say that? It makes no business sense for them to disallow competitors with their eventual SDK because they will still be selling much more expensive hardware to those people.

With an SDK they can only sell more products, whether that is apps, hardware, or both.

Where they should limit their SDK use is in branding — they probably wouldn't want poor quality or badly designed apps advertising (or even using) the Pencil SDK. It would reflect badly on their product. So they need to maintain control in those cases.

They shouldn't allow "any kind of app." They should allow "any kind of app that meets their standards for quality."


Don't assume there won't be an SDK for Pencil, too.


But "Pencil" probably won't work with Adobe apps, am I right?


One of the most insightful comments I've read on HN. Love your idea of taking the Unix approach to hardware - don't know enough about hardware hacking to know if that's doable but I like the idea!


The current trends in mobile apps, and smartphones pushed such "silos" of functionalities not open to other devices, forget hacking. It's time for someone to develop an open source hardware and make all the protocol open, and maybe call it "finger"..

Edit: on the other side, we have Rasperry, Arduino etc..


Hardware abstraction is like the Holy Grail in the test and measurement world. Things like the IVI have been implemented but have not gained traction. Once you have a feature that is slightly different than other instruments what do you do? Least common denominator in feature set has been the solution so far. Not saying a way for OS-level abstractions isn't bad, but there are niche areas in computing that have tried and failed at solving this problem.


It's pretty natural in a new niche for there to be experimenting before it settles down to a standard. Either the OS makers pick it up and we get standard API's in Android and iOS, or someone organizes a standards effort for the vendors to get behind. But standards committees are slow and negotiating a new standard isn't what you do when you're trying to ship 1.0.


the older and more experienced I get I increasingly see that pattern: those who don't really know/understand Unix, vi or Lisp seem doomed to reinvent them, typically poorly, more expensively, more convolutedly, more bureaucratically/monopolistically, etc. Not to say they're perfect in all ways, or 'complete', only that I've lost track of the number of times where someone went with a much more complicated/expensive/indirect/expensive solution when they would have been better off with something provided/encouraged or exemplified by the patterns of Unix, vi or Lisp.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: