Nice! Playing spacewar on the real hardware was one of the big highlights of my last visit to the Mountain View Computer History Museum (the other one being seeing the recreation of the Difference Engine actually working).
If I had to guess the reason, I would say that the new Windows devices are going to include many more small screens, which MS forecasts will make secondary (bigger) displays much more common than with traditional Windows PCs.
Looks interesting. A little bit of feedback:
- I didn't like that the table of contents disappeared on me when I clicked on a page.
- Related to this, it would be great for the progress widget to show the actual name of each page/chapter, if not all the time, at least when you hover with the mouse.
- In the table on contents: mark in some way the links that are going to take you away from the book and into a github view.
- The Next button feels too big in pc. Takes away the attention from the content itself.
Thank you for your hard work!
I completely agree. I didn't like that the table of contents disappeared. The page also made me feel like scrolling but that isn't supported. Awesome work!
What materials could we use to prototype? Cheap materials and rapid construction should probably take precedent, to ensure speedy iterations by a large number of people.
Not really. In Java it's a leaky abstraction - it's true that the JVM does a lot of micromanagement for you, but if you are careless you start getting exceptions (best case scenario) or start to get mysterious changes in your data (worst case scenario).
I agree with grandparent that understanding what a pointer is and that almost everything in a Java program is a pointer it's critical for a Java programmer.
Hey there, I just tried it and my experience was not very satisfactory. I imagine you are interested on the feedback so there it goes: video quality was low (super choppy, video was getting frozen at several points), voice quality was low (I could understand about 50% of what was said) and when a third person tried to join it got a message "This call is full right now" (which I don't know if it's a bug or by design - it's not clear if this is just a 1-to-1 service).
Anyways, the concept is very cool and I hope you get to make it work. A reliable service like this would remove a lot of my communication headaches.
Thanks for the feedback, sorry your first call didn't go well.
When the connection is poor, as it sounds like it was in this case, would you be okay if we fell back to audio-only and explained why? This seems like a better experience than trying to fight through lag, but we want to be careful not to arbitrarily cut off your video feed.
In Skype I have the option to show call technical info turned on.
It is immensely helpful since it shows continually updated values for latency, packet loss (in both directions), codec in use, bitrates etc. From that I can easily tell what the issues are (latency spikes vs packet loss are hard to distinguish due to the same symptoms).
That isn't helpful for the masses, but you can display some sort of connection quality indicator. You can also offer suggestions on seeing latency spikes or packet loss (try to work out of they are upstream or downstream).
The usual solution to video is to reduce bitrate, resolution and framerate. Blocky video that is taking seconds to update is an obvious indicator of connection quality issues.
Thanks Roger -- we really want to create a connection quality indicator like you describe, kind of like the number of bars on your cell connection.
One of our biggest frustrations with existing services is that it's hard to tell why the call quality is poor - is it my connection, your connection, or the service's fault?
Can I shoot you an email when we get a beta version of that indicator working? I'd love to get your feedback on it.
We are collecting anonymous data about the network, browser, etc. and tying it back to core metrics like call length, but there's always more we can do. I'm really hoping that more browsers start to support the network information API natively too: https://developer.mozilla.org/en-US/docs/WebAPI/Network_Info...
The flip side of spreading your data across several providers is that you are increasing the odds of finding a problem. But the problem will have a smaller impact (hopefully).
But you're not actually splitting your data across several providers, in many cases, you're making copies of the same data, and so you're actually increasing your exposure.
