I think it's interesting to ask people who are educated in China what they think about the Tiananmen Square Massacre. For instance, what do they think about this photo? https://i.imgur.com/0zAQqAO.png
Though, this line of questioning may be met with hostility. So I suppose you could ask them why they're angry about evidence of a massacre of their own people.
You can set your state of mind along with your status now, so I guess this isn't really surprising - if that's how they do it (I only skimmed the article.)
What's new, really? This is just another data point people are willingly handing over for Facebook to sell as per the terms of service.
You can ask them to pay you in cash as long as you don't accept the offer before hand. They're legally required to compensate you with cash if you ask.
I just bought an Ableton Push. I plan on cracking open a beer and learning to use it after work. I figure if I'm going to entertain myself I might as well be learning too. I find making music to be both engaging and relaxing.
With regards to taking an instruction and converting it into a state representation, I think creating music is very similar to programming. Coming from a web background, I've seen experiments like React Music which I think are really interesting. If the question becomes "how can we best represent the changing state in code?" Then I think that's a question that can be solved for both interface programming and music programming at the same time. This is why I find React Music interesting: React's declarative syntax makes it easier to understand what the final product is going to look like. Can the same thing be done for programming sound, in a way that represents the final product in a more naturally understood way?
I've spoken about this before on here. We developed on HoloLens for a couple months. Working on the HoloLens app was actually my first foray into 3D development, and also required converting ThreeJS JSON into Unity models which was a mess.
The user experience
--------------
HoloLens is mesmerizing. I'm not big into VR or anything, and will often make the arguement that VR hype will die out and is a fad. But there's something very different about what Microsoft is doing. The ability to incorporate reality as a first class citizen in your 3D applications (or vice versa) is groundbreaking. People often complain about the FOV when they first try it out, and I had the same complaint, but your brain is able to compensate once it gets used to it, and then you stop noticing it. That's something you don't get from a short trial of it at a tech demo. The user inputs are indeed very clumsy still. We'll need vast improvements in this area before HoloLens can feel immersive. But the amazing thing is that this first pass isn't that bad. It can track your hands and it's a computer that sits on your head. I mean, come on! I'm only 22 and even I think that's amazing.
The developer experience
------------------------
One of the major short comings of HoloLens development is its dependency on Unity. C# isn't the problem. I love C# and use it daily now for web development. The problem is Unity uses .NET 2.0, and good luck finding C# libraries that are compatible. So for every new thing you want to do, you're going to have to find a "Unity compatible" C# library, which is very annoying.
Unity will work for what you need most of the time, but it turns out if you want to try something custom (like your own gestures) then you're out of luck, because the Unity APIs are limited in that way.
I suppose I'm mostly just not a fan of Unity's component model. Constantly switching between adjusting settings in the IDE and coding feels like a bad way of developing.
Okay, so maybe you want to try something a little lower level. Microsoft offers a C++ API as well, and for the most part this is what you want if you need to harness the limited power of the HoloLens. I haven't played around with all of the APIs, but I know of one in particular that left a bad taste in my mouth (this applies to Unity too) -- the spatial anchor API. For those of you who are unfamiliar, the spatial anchor API is the only way to acquire a durable and persistent reference to a real world location. This is done (I think) with sensor data (orientation, lighting, and images captured by the 4 on board spatial mapping cameras.) This is really an incredible feat of engineering, however it produces a binary which is around 15MB. Far too large to store in a database at scale. I'd like to see MS open up raw access to those sensors so middleware developers can try their hand at improving this aspect of HoloLens.
If C++ isn't your thing, there's a library called HoloJS. You guessed it, it's a JS runtime for HoloLens with access to native libs. I actually started my own variation on this (called HolographicJS) before Microsoft released theirs, but I'm happy they've taken over.
The future
----------
So what does this all mean for a device that seemly has its share of problems to overcome? Well, after trying it I'm fairly confident that MR as Microsoft calls it, is here to stay. The ability to mix reality with virtual reality, and augment that with a layer of environmental understanding is really incredible. I think we're just scratching the surface of the possiblities.
HoloLens is the first in a new field of devices that I believe will come to replace all forms of computers we currently use: phones, laptops, desktops, tablets, etc. Even things like IOT devices. Why spend time building your own interfaces when you can just augment the users'?
If v2 had better FOV and improved input tracking, I'd consider it a major success. But if it also included improved spatial mapping and a reliable GPS, that could bring us into a whole new world, quite literally.
The way I see it, the first company to solve outdoor use of an MR device, and solve what I'm calling the "universal spatial map" problem, will run the world of tomorrow.
Imagine every machine being capable of interfacing with you without the need for a screen or separate device. Imagine walking down the street, gesturing to a restaurant and placing an order before you even get inside.
Further down the line. What if we could transfer consciousness out of a dying car crash survivor into a computer. What if that person could then be virtually transferred back to the scene of the accident, to be greeted by those who are augmented.
Anyway, that's all crazy futurism; but the point is that reality starts with what is being done with HoloLens, and I think it's an incredible thing to be a part of.
I'd like to see where people are from if they're replying to this thread. I wonder how cultural norms affect effectiveness (do Americans work less at work because of the work-oriented culture which requires them to stay at work longer for no reason?)
I've had the (still fairly unique) opportunity of actually having to make very different considerations with regards to user experience. This came in the form of designing for HoloLens. I bring this up because I believe in 5 years we'll be much closer to realizing the potential of VR and MR (mixed reality, like HoloLens.)
I do think VR devices will live a short life and die off. VR (in the form of a single purpose device) doesn't really have a place once a device can provide both augmentation and a totally virtual experience. I don't think we're far away from that.
Certainly what we'll see is a uptake in MR devices. I suspect future iterations of HoloLens and other MR devices will bring forth a desire to experience and incorporate MR. Some businesses are already jumping on the opportunity, but in my opinion the technology isn't quite there. In the case of HoloLens, it's clear it still lacks a real understanding of intuitive input.
I think one of the big mistakes people make when considering new UX patterns in 3D space is that not everything is designed for 3D space. And conversely, not everything designed for 2D interfaces works in 3D. You can't just move your app to VR. Certainly you'd think it would be rather strange if a restaurant provided its menu as a stack of blocks. Some interfaces are indeed better suited for 2D, so for that reason I believe there is a place for some 2D interfaces in a mixed reality future.
The other big mistake I've found people make is the idea that in order for something to have great UX, it should mimic real life. Perhaps this is true in some cases, and if you're building a product that's designed to mimic real life then that's probably the best choice. But new experiences will undoubtedly emerge (more often than not, I suspect), experiences which are foreign in concept to us now because its simply not possible in our physical world, and that will be a real test for UX experts out there.
One thing we will need to focus on is understanding what it means for an interaction to be discoverable. A lot of people seem to think voice is intuitive, but I don't think that could be further from the truth unless you've got a general intelligence to talk to. No one thinks automated answering systems are user friendly. Even with general intelligence it can be hard to put your intention into words when it comes time to "take an action."
Personally I think the optimal solution for these types of interfaces will be a mixture of context awareness and neural impulses. If I can look at a TV, and the device can see what I'm looking at (on board camera also sees a TV) then it has an understanding of what actions I might be interested in performing. At that point it can show options in 2D above the TV or however you want to lay it out. I'd then be able to look at the option I want (device tracks pupils and knows with accuracy what I'm looking at) and think about touching it. This impulse acts as an "invoke" action on the current thing I'm focused on.
If this stuff becomes possible, then that's about as low friction as I can think of without interfacing with the brain. Will be be there in 5 years? Hard to say. I'd be willing to bet we might have something that gets us partly or mostly there, and may have to be tethered to a secondary device like a phone for additional processing.
.NET Core support is a little ways out still last time I checked, but it seems to be running at this point. IIRC, the Orleans team is working through kinks and compatibility to get it to 100% feature parity.
We've been working with Orleans for a few months to build out the next iteration of our infrastructure. I have nothing but good things to say about it. One of my favourite aspects of developing with Orleans is its single-threaded nature. Because a grain can by default only process one call at a time on a single thread, it's easy to make guarantees about data consistency inside that grain regardless of how many processes are reading/writing to it at once.
The idea of a stateful grain is also really powerful and something we're harnessing extensively: if everything is a grain, all of your data is already cached in the activated grain so there's no need for a separate caching system. Additionally, any updates to the data are immediately available to the "cache" before you send it to the database. So transient data can be cached even if you're not sure you eventually want to persist the data. This allows you to do partial application of data to grains, and then eventually commit the data to storage (in the case where writing is expensive.) This of course is totally possible with more traditional architecture, but its impossibly simple in Orleans and it's hard to go back once you get to use it.
I also want to give a big thanks to the folks who are active in the Orleans Gitter channel. Honestly probably the most helpful open source community I've ever encountered. They're extremely thorough and always willing to help.
