Accurate and fast facial recognition (combined with cheap public cameras and abundant cheap storage) is one of the few technologies that makes me truly dread possibility. I don't want to live in a world where all travel outside of my house can be reconstructed and scrutinized at a later date, even if the only party with that ability is the government.
As a user of both windows phone and windows on the desktop; I'd be much happier if the desktop start screen experience were more like the phone one.
Phone: Here is a surface, arrange and size your tiles as you like, anywhere in available space.
Desktop: Here are groups, size your tiles and we'll auto arrange them in sequence in the group they are placed in.
You can be a touch more creative with the windows phone variant; and the experience is more intuitive when you're shuffling your tiles around.
Then again, the windows phone start screen does not react to screen orientation changes, meaning the surface you place your tiles on will never change size or orientation. I can see how the concept of groups answer the "how do we arrange to fill screen when orientation changes without bothering the user too much" question quite neatly; but I hope another few meetings around the drawing board on this issue can produce a more personal experience (rather than the current compromise).
I'd be happy to enable an option to have more customization options, even if it meant laying my tiles out twice (once for portrait, once for landscape).
I hope they don't do away with the start screen completely; I've gotten used to it and rather like it. Operating a surface taught me it's value.
Let me clarify. None of that was an insult. He has talent. It takes a lot of experience to harness and balance it properly. As he matures he'll figure it out. He's 24.
Building something pretty is one talent. Building something novel yet still intuitively usable is another. Building something engaging is yet another. They (and more) are all linked. If he gets them all (or even just a few) down and balanced he'll be someone to look out for.
I see talent. This is a nifty display of technical prowess. I don't see discipline or any concern for the experience of the user.
Having spent some time in the explorer section, what I see is something pretty, but unreadable. After the novelty of the interface choices fades, it's about as engaging as an XML document. There's no story here, no human element. I am seeing some interesting ideas and uses of space wasted displaying useless data. The experience is disjointed, the navigation is not intuitive, the page does weird things on scroll, and it doesn't work in IE11 (which is more offensive to me than it likely is to most of his audience - I switched to chrome to play with this).
If I were looking through this as a portfolio piece, I would be impressed with the technical elements of the design, a bit put-off by the usability problems, and confused (and a little upset) as to why a record of travel to 72 cities is presented in such a dehumanized manner.
I concur. It wasn't until I started working with an OSS guy that I realized how different (sometimes frustratingly so) the OSS mindset is.
I wont try to draw any conclusions here because I don't know how much of our personal conflicts are caused by our platform ethos, and how much is just personal; but I can say that the way we execute architecting and building novel solutions is completely different.
I am totally behind the spirit of your article. I also believe it's a travesty that we have so much power that can be attained so cheaply, yet we aren't using it at home.
It's a big industry out there. There are those who make bespoke products, and those that take a number of pre-built more general purpose libraries and just stitch them together, and everything in between.
Stitching together libraries is easy and generally quick to produce an initial product, but can become difficult to maintain/extend and is wasteful on both run-time and development resources. This method is pretty forgiving to those that don't know exactly what they are doing, and you don't have to have any experts on your team to produce a "working" product. You will accrue lots of technical debt this way (but in a lot of projects is doesn't matter much).
Bespoke products are difficult to architect and build (properly), take a long time to develop, but are performant, malleable and predictable when done right. If you do it wrong (or your architect is hit by a bus), you have a huge mess on your hands.
Most of my experience has been about two thirds bespoke, one third stitching. In my experience, finding the right ratio depends on the amount of scaling the product needs to do, how much you're willing to spend on talent, how unusual your requirements are, and how screwed you're comfortable being if things go wrong.
I have never seen an instance where a well built bespoke product did not have a competitive advantage over a stitched one. Generally a large competitive advantage. I have also seen a number of poorly built bespoke products crash and burn; so take that as you will.
I think I see where you're coming from. Correct me if I am wrong.
If I were solving the same problem:
public void CreateBooking( int chosenBookingType,... ){ ...
- and -
public string[] GetAvailableBookingTypes(){ ...
or something similar.
Your implementer can call GetAvailableBookingTypes at run-time to populate whatever interface lets you select one, then pop the index of the selection back into CreateBooking. I have it returning an array of strings as a very simple solution; you can just as easily return an array of objects that better represent your booking types (containing descriptions, and URIs to icon images or colors or whatever). The methods are named in such a way as to lend to the fact that they are related. No enums, no wonkiness and you can add new booking types at will without having to let your implementer know something changed. If your implementers are not catching on that the two methods are related, you can solve that problem with easy to read documentation.
I'd much rather have a second image with a gray scale depth map. I took a look at the lytro, but it appears they have some weird proprietary image format.
WPF (not a language, it's a desktop UI framework):
Windows Media Center (you have to jump through hoops to get it on modern windows, but I feel it's worth it).
Here's what it looks like for those who aren't running windows or don't want to install.
http://youtu.be/MSvME6zR7gU
As far as I know it hasn't changed much since Vista. I still consider it one of the best examples of what a WPF experience can be like.
You can use WPF with any CLI (.Net) language, but C# is preferred. WPF is windows only (windows presentation foundation) and can't be used with mono as far as I know.
Bart de Smet's book "C# 5 unleashed" is a good place to start. It's an excellent resource and takes you from beginning concepts far into advanced ones. It's really all I'd recommend without any more information about what specifically you want to do with C#.
They ARE a thing. Work for any large and successful software company and you'll find (or hear stories about) at least one. Look for the people that are consistently put on mission critical projects.
There are more types of extraordinary developers, but 10x is the only one I hear consistently mentioned.
"The core of the software is ultimately pretty simple, however it really needs to be custom tailored to each organization. Some groups want to track whether artists are persons of color, some groups want to have explicit fields for evaluating, and some just want space for a recommendation and a way to attach an in depth review, and every organization believes that theirs is the one true method. These changes are all pretty simple to make, however they are large enough and sometimes architectural enough to make building one monster app and database with support for all the iterations rather imposing. Especially when I can't afford to work on this full time."
"Do I try to make one monster app that can serve every organization, risking complexity, less flexibility, and security? Do I just try and optimize and optimize until it can run happily on a less beefy machine? Or do I have too many pre-conceived notions about how customers think, and I just need to pump out a project, set a price, and start going? Help!"
This seems like a problem that can be solved with some pretty basic OO in your business logic layer, and a little creative database work. One system to run all of the sites will save you headaches in the long run. It will likely save you some money as well. Were I in your situation, I would certainly go with the one central system approach.
Off the top of my head, I'd be creating one set of abstract business logic classes that contain what your clients have in common; and a set of abstract methods that will return objects that contain data they do not. I'd create a class inheriting the abstract one for each client, each containing their custom requirements. I'd create a view layer that can adapt to the custom data, and a data layer that is capable of storing the custom data. Let me know if this is too vague.
"Super Windows X Turbo: World Warriors Edition" sounds pretty sweet to me.