I don’t know how a real designer does it, but when I attempt a design, particularly a blog design, I always start with a simple theme. If the ideas begin to flow, I’ll know I chose well. If not, and I still think it’s a good theme, I’ll visit the usualsuspects for some inspiration.
On this blog, I started with robots, which quickly lead to gears and mechanics. For this post, I started with circles. Actually, I started with Ironman’s HUD. The whole movie was super cool, but the HUD was the best. And the HUD had all this motion and targeting, and that’s what got me to circles. So that’s the theme. I already know I’m going to apply this theme to a simple grid-based blog layer that I discussed earlier.
Palette
After the theme, I worked on the color palette. I’ve used Kuler in the past to build out a couple of palettes, but this time I just jumped into Inkscape and started messing around. I came up with a nice blood red and black palette.
Circles
Now that I have a palette, I shift my design focus back to circles. It’s not just gonna be “Dot, dot, dot” as my daughter likes to say, so it’s back to Inkscape. Here’s the result:
Layout
Not much left but the real work – make a cool blog design with circles plus some pretty colors. I know my layout, so once again it’s back to Inkscape. There is a nice Inkscape template generator for Blueprint CSS grid layouts. Choosing which colors go where isn’t too bad, because I love dark text on white for blogs. Following that decision, I go with lots of circles in the header in blood red, over a black background. We know the main content will be white with black text, so I decide to make the sidebar really stand out with a bold blood red.
The circles in the header are really easy, I just pick random sizes and put them in random locations. Darker usually means further away, so I just reduce the opacity to let more black through. I use a rounded rectangle with a thick stroke for the main content area. I also add a black shadow around the entire content area to highlight the content. The finished design is here, and I’m calling it Circles Of Doom. Here is a closeup of the header:
Having established (ie, forcefully asserted) that it is generally Bad to engage in ritualistic development practices, but Good to adhere to a particular practice when it's well-suited to surmounting some challenge, let's consider the first snarling beast that leaps out to menace most young, impressionable development projects before they've even secured funding -- requirements definition.
Functional requirements are strange and mysterious things. Many programmers have never actually seen any, relying instead on rumor, innuendo or hearsay to guide their development objectives. For many, functional requirements are the only things keeping programming from being their dream vocation. Programming after all is, at its best, a beautifully artistic endeavor wherein we devise clever structures to manage the complexity of some problem, and transform chaos into order. Implementation "elegance" is regarded as one of the highest achievements we can attain as developers. As each new project begins, we think wistfully of the various forms of abstraction and all the intricate frameworks we have mastered over the years, and consider how, armed with the depth of our experience, this project will surely be different from our past ones. This time we'll build the thing Right, methodically assembling a great edifice from a series of simple building blocks. Each will be as cohesive as the nucleus of an atom, but as loosely coupled from one another as the grains of sand along the seashore. You kick off your shoes, and wander along the beach, smelling the salt air and thinking about that time under the boardwalk -- then, suddenly, a subject matter expert comes marching down the beach with several unruly business owners in tow, and all hell breaks loose.
Real-world requirements are seldom elegant. On the contrary, they tend to be maddeningly messy. For many applications, the hand-waving of some business stakeholder-guy can be sufficient for reaching an understanding of what needs to be built. But, alas, the majority of applications we build are far more "interesting" than these. Confronted by the terrifying unknown of some obscure workflow that has evolved over millions of years and countless mergers and acquisitions, many developers immediately fall back on their religious texts for guidance and comfort against the onrushing horror. They begin frantically writing user stories, drawing anatomically inaccurate stick figures, and in the dark of the night wondering why the gods of order and logic have forsaken them despite their best attempts to follow the good and righteous path documented and indexed in their most venerated religous text (second edition, totally updated with a new preface by the author).
Why must it be so? Why do business requirements, which on the surface seem so simple compared to the complexity of the software platforms we, as accomplished software developers, whip into submission almost every day, so often defy our best efforts to wrestle them to the ground though we pelt them with CRC cards and lock them in use cases? Is there no way to reduce the arbitrary tangle of business rules to some elegant expression of the problem that can return us to our idyllic afternoon at the seaside?
Grab a towel and some sunscreen and allow me to introduce you to Precision Requirements Modeling.
A few weeks ago my co-workers and myself spent a few hellish (but fun) days with significant performance issues on the eve of our first release of a Flex application we are building for a Gorilla Logic client. First off, the majority of the issues were unrelated to Flex, but architectural choices outside of the presentation tier that we do not have much say in. However, we did encounter a major challenge with Flex’s ArrayCollection.
Due to a somewhat unusual data set, we have a large number of ArrayCollections being returned in our Object graph, and we were experiencing a large time lag between when Flex reached the result handler and after BlazeDS had finished its work. Times ranged from 10-60 seconds depending on the size of the data set. After a decent amount of analysis, we discovered most all of this time was related to the performance hit of instancing an ArrayCollection.
By our testing, we were experiencing an 18x difference between instancing a large number of Arrays versus ArrayCollection. We measured this with a simple program that just instanced 100,000 Arrays and then 100,000 ArrayCollections. In addition, we tested with BlazeDS returning Arrays versus ArrayCollections and saw the same 18x difference.
The solution for us was to have BlazeDS return Arrays instead of ArrayCollections, with the legacy-collection setting. This is obviously a decent trade off, as Arrays lack much of the essential functionality of ArrayCollection. The root problem with ArrayCollection is the number of events that dispatches, and there are the methods for enabling and disabling “auto updates” to turn this off. However, it is possible, but difficult to do this before Flex client reaches the result handler.
Beyond making instancing ArrayCollection faster, it would be nice to have the option to easily disable this behavior with a configuration property. Here is the feature request I made: http://bugs.adobe.com/jira/browse/SDK-17916. Please go vote for it!
I don’t usually get off the technical tracks with this blog, but what an amazing night for America. I know that about half the country will be disappointed with the election of Obama, and I think it is ok to be disappointed if you don’t agree with his politics. Regardless, I think you have be excited that this country elected a black man tonight. We cannot change the bad things in our past, like slavery, but I think we should all be enthused about the uniqueness of this country. To quote Ronald Reagan, “America is a shining city upon a hill whose beacon light guides freedom-loving people everywhere.” There have been a number of lowlights for our nation in recent years. It is awesome to remember what is possible here.
Programmers are a religious sort, unquestioningly engaging in ritualistic practices pronounced as "good" by the industry's high priests, and likewise shunning those practices branded as blasphemous. Everyone knows for example that mixing business logic with user interface code will damn your soul to Hell for all of eternity. Likewise, engaging in waterfall development leads to nowhere but poverty and pestilence. And each time you use dependency injection, an angel gets his wings.
The religious tenets of our industry of course have mostly arisen from hard-learned lessons about what seems to generally work and what seems generally not to. Still, it is clearly the case that there is no single path to project nirvana. Every development initiative grapples with a unique variety of technical, political, and sociological challenges. Some projects even succeed. It is of course natural that people examine the practices used by the really successful ones, and strive to emulate them to maximize their own chances for salvation.
Successful software development, alas, cannot be achieved by blindly following the prescriptions laid down in some sacred textbook or blog posting. The sacred texts do indeed provide valuable techniques discovered only after the spilling of vast amounts of blood by our ancestors who came down out of their mainframes to spread out across the network, converting green screens to rich clients, and procedures to objects. So, let us embrace the tools and techniques, but let us also recognize that the reason software projects fail is that there is no "Way" that one can simply follow to guarantee success.
Software development projects present us with a series of challenges. Each of those challenges can generally be addressed with some established set of tools and techniques. When we complete a successful project we are typically tempted to look back on the steps we took along the way and announce to our colleagues, "Ah, yes, truly we have found The Way. Let The Way be written down so that it be made repeatably so, and we can look forward to nothing but happy days for ourselves, our managers, and our manager's managers." And yet we then see others try to follow The Way, only to find misery, chaos, and even death. Okay, maybe not death.
So are we condemned then to roll the dice each time we undertake a new development initiative? I don't think so. But the solution is not religion. The solution is in learning a few highly useful techniques, but rather than applying them ritualistically, we should instead learn to assess the particular challenges presented at a particular juncture of a particular project, and to select among and adapt the various techniques to the challenge at hand.
Posted in Glen Whitbeck on November 3rd, 2008 by admin
I was recently working on a task with Jon Rose (Jon’s Blog). We basically needed to implement the typical summary-detail functionality.
At a high level, we needed to show a DataGrid containing a list of items, along with some summary information about each item. The user would then select the item that they wanted to work with. At that point, we would remove the summary list and display the details of the item.
Removing the summary list allowed us to save screen real estate by removing now-irrelevant information (the user no longer needed to see the items that they did not select). However, this also meant that we were no longer displaying the summary information about the item that the user did select.
Although the summary information is typically present in the detail section, it is usually preferred that it also be presented as a header or title above the details. We could have created a Label to display this header/summary information. However, we already had a DataGrid row that displayed exactly what we needed. Furthermore, at this point, the user is already accustomed to seeing the summary data in this format. We wanted to keep the flow from summary-view to detail-view as obvious as possible.
What we really wanted was to keep the summary DataGrid, but shrink it to only show a single row. That single row should only show the item that the user had selected. We tried setting the row count to 1 and scrolling to put the selected item in view. But, that led to dealing with a scrollbar and some other annoying issues.
What we decided to do, instead, turned out to be much more simple (and, in hindsight, seemingly obvious!). Instead of trying scroll a DataGrid to the proper item, we created a filter to eliminate everything except the selected item. At that point, the DataGrid would only contain one item (the selected item). Thus, we could set the DataGrid’s row count to 1, and not have any of the other issues (scrollbars, etc.). Here is an example:
This behavior allowed us to keep the selected item’s summary information available in the form that the user was used to. It avoided the creation/maintenance of another way of displaying the summary information. It also allowed us to reclaim screen real estate. And, it was simple.
The remainder of this page discusses the code behind the example. I have omitted things like widths and resizing effects in an effort to simplify the conversation. First, we create your basic DataGrid:
We will also create some buttons to allow the user to either update the data with any changes they made in the details section … or to cancel any changes they may have made.
And, here are the functions that are called by the selectStock(event) function:
private function filterArrayCollectionToSelectedItemOnly():void {
//assign the filter function to use
this.stocks.filterFunction = filterStocksToSelectedItemOnly;
//run the filter
this.stocks.refresh();
}
private function filterStocksToSelectedItemOnly(item:Object):Boolean {
var thisIsTheSelectedItem:Boolean = false;
if(item == this.selectedStock) {
thisIsTheSelectedItem = true;
}
return thisIsTheSelectedItem;
}
private function collapseDataGridToOneRow():void {
stockDG.rowCount = 1;
}
private function displayDetailsOfSelection():void {
this.companyDetail.text = this.selectedStock.companyName;
this.symbolDetail.text = this.selectedStock.symbol;
//... (continue setting remaining values)
showDetailsAndButtons();
}
If the user wishes to return to the summary list (by clicking either the Update or Cancel button), we will reset the DataGrid to contain all of the items by removing the fiter, calling refresh() on the collection being used by the dataProvider, and setting the rowCount to the number of items in the list. In addition, we will remove the details section and the buttons from display.
I’m a bad designer. No amount of ego, or sugary coating can change that fact. Whenever I hang out with my coding buddies to talk design, they actually think I might border on decent. It’s either midget aliens piloting their husks or their brains have been pickled from over-exposure to Hibernate mapping files. Thankfully, I’ve been around some real designers and they know the truth…if it’s brown and smelly it must be a turd.
I do, however, know what I like. And when I’m build a blog, I like to have a header, footer, main content area, and a sidebar or two. Since I need all the help I can get when it comes to website design, I always try to leverage what others have done. In the case of this blog’s design, I’m using Blueprint CSS, a bad ass grid-based CSS framework with smart typography defaults.
But before I dig into the details of my design, I want to start simple. So imagine we want build a website with your basic two-column layout.
Coding a basic layout like this one is almost too easy with Blueprint:
