Sogeti Phoenix Blogs

Design matters. The User Interface of an application, be it web or desktop, is one of the most, if not the most, crucial part. Why? Because to the client and/or customers, it is important to them, though they may not know it.

It's been said before, but to the customer, the UI is the application. You might have developed the fastest, most efficient algorithm, but if the user cannot use it, then they just won't.

To be clear, "design" is not necessarily the aesthetic look and feel of an application. Pretty and shiny contribute to the overall sense of design, but do not make up for shortcomings. In fact, there are plenty of command line driven apps that have great design. They ain't pretty, but work great. And once you move a little bit up the learning curve, they become second nature.

Good design can be obtained by non-artistic types. One of the most common myths I hear is that people think you have to be be "A Designer" to do good work. The most common response I hear for  a terrible work is "Well, I'm not a Designer."  Yeah, that might be true in HR's filing cabinet, but it just strikes me as a lazy excuse. Or something that Eeyore would say, "Oh well, I'm no good at this. Why even try? I'll just stick to aquamarine and fuchsia." No, your job title might not say "Designer," but it also probably doesn't say DBA, yet you probably have some working knowledge of how SQL works right?

There is a talent aspect to it, but like everything else, talent is worthless without the work to reveal it. And talent is kind of like temperature anyway; there is an absolute zero, but it cannot be achieved in nature (even with quantum effects). In reality, even the most inept can achieve adequate, or even good, design if they apply enough effort.

Where does good design come from then? John Gruber points out that too many people believe that design is just something to worry about at the end of a project. If you say, "Oh, all we have left to do is the UI," then you might as well just drive it off a cliff right then and there.

In the end, a good design ultimately benefits you. The work you do reflects who you are and how your clients/employers see you. And their first impression is the design of an application, so doing a shoddy job is only a disservice to you. It is not easy, but what in software development truly is?

Interesting issue Shawn and I ran into today with the <script> tag in ASP .Net. A page was defined with <script> tag that was closed with a /> instead of </script> as shown below.

<script language="javascript" src="myJavaScripts.js" type="text/javascript" />

And any time a control on the page did a post back it started throwing java script errors such as "Object Expected". Other variants could be "__doPostback not defined" but I did not see that error. Anyway the culprit was the /> closing tag. So to fix the error I had to end the <script> tag with </script> tag instead of />. So changing the above statement to

<script language="javascript" src="myJavaScripts.js" type="text/javascript"><script>

fixed the error.

Incidentally this worked also.

<script language="javascript" src="myJavaScripts.js" type="text/javascript" />

<script></script>

Go figure.

Team Foundation Server (TFS) has a great feature called shelving. It allows you store a copy of your source code changes on the TFS server. Please note that this is different from checking in the code, because the copy is set aside temporarily or shelved under your userid. Since the code is not checked in you can be confident it is not going to break your team's nightly or continuous build.

There are several ways to shelve your changes. The easiest way to do it is from Visual Studio, click on your Pending Changes window, and select the files and click Shelf button. In the dialog window that opens up enter a Shelveset Name and click Shelve. If you give a Shelveset Name that is already existing it will ask for confirmation to overwrite it.

For unshelving, open Pending changes window in Visual Studio and click Unshelve. By default it will show you all the shelvesets for your userid. Click on the self set name from the list and click Unshelve. It will bring down your shelved code files to your local workspace automatically check it out from the TFS server.

For more ways including command line to do shelving and unshelving look at the MSDN documentation here.

Some of the uses of Shelf feature are:

• Set aside temporarily a feature or some code change that you are working, because you are now assigned a different task or a bug to fix.
• Collaboration on a code change. Say you are working on a code change and you need some extra information from another team member to finish it. You can shelf your code and have your team member unshelf it and provide the extra information and check it in.
• Use it for code review purposes before checking it in for build.
• Use it as a personal code change backup. I normally give a shelfset name of bkp (because I am lazy), and allow the confirmation dialog to overwrite my existing backup. You still have to remember to manually do this though. I have made it a practice to do this before I leave for the day. May be I will automate this some day and blog about it.

For more information about shelving and unshelving look at MSDN documentation here. There is also a 10 min video here that gives you a hands on approach.