computerslol

"Super Windows X Turbo: World Warriors Edition" sounds pretty sweet to me.

Did we forget about a big chunk of apple history? :)

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.

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.

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 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.

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.

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.

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.

I work in Visual Studio on things that have nothing to do with Linux and am ignorant of the profundity of this product.

There are more types of extraordinary developers, but 10x is the only one I hear consistently mentioned.

"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.

http://channel9.msdn.com/shows/Going+Deep/Bart-De-Smet-Obser...

Although this blog is dead now, the information stored within is golden. I also highly suggest De Smet's C# 5.0 unleashed book.

http://rxwiki.wikidot.com/101samples - A cursory look; it goes far deeper than this.

&nbsp; and 0.gif (fewer characters!) bring back memories. What I miss most was the hacky tricks you'd have to put together to get load times down on dialup. Carefully controlling the order in which things rendered. Early DHTML. Slicing layouts so that as much as humanly possible the images repeated. Tables tables tables. IFrames that talked to each other. The javascript that converted <div>s to <layers> for netscape.

In those days I was certain there would be a complete replacement for HTML/JavaScript/CSS that would take over. Flash came and went. Silverlight was a lovely attempt. We just kept layering lipstick on our pig :).