Innovation Treadmill

The longer a software product exists and is being actively developed, the more changes are going to affect its development.

The kinds of changes are various, ranging from new technology, new development tools, new development paradigms and trends, to changing requirements and solutions, or complete shift of focus.

I’ll just summarize some of these changes that may apply to my projects (and probably yours as well):

Old New
Framework ASP.Net ASP.Net MVC
PostBack Ajax, In-page update
Client-side scripting Ajax Control Toolkit jQuery
Javascript TypeScript
Data Access SqlCommand (aspx, C#) Data Access Layer
XML Generation StringBuilder XSD, xsd, XmlSerializer
Parser DIY NIH Antlr
Focus (e.g. VSSlnVis) Graphical representation of dependencies Textual analysis of solutions and projects
(e.g. dbscript) Generate C# constants, Generate CREATE scripts database versioning, documentation and deployment
Patterns? Anti-Patterns, God Objects, Spaghetti Patterns, Lasagna, Ravioli

If your project finds itself in a sort of identity crisis, then don’t worry. Companies and organizations bigger than yours often recognize the need to re-write:

KDE did it, Mozilla did it, phpBB did it, and Google just forked Webkit into Blink to be used in Chrome.

So I came to the conclusion that to increase maintainability and extensibility of the programs and projects that I still update (some more frequently, others less), I need to rework their code.

As I prefer my principle of the least technological requirements, I am still not sure whether to stick with .Net 2 for my WinForms apps, or whether .Net 4 is already acceptable (i.e. does not require the user to separately install specific versions of .Net).

Please leave a comment with your ideas 😉

Fixed layout, variable layout, or something completely different?

If you are working on a web application, sooner or later you come across the question of layouting your pages, and you’ll notice that there are a couple of (accepted) choices:

  • Variable (fluid, full-window) layout
  • Fixed layout (centered or not centered)
  • Elastic layout (what??)

Full-window layout is most likely the simplest and earliest web layout. If you create a plain HTML page, the contents will take up the whole width of the browser window. You’ll notice this if you browse pages from the early days of the web, and it’s immediately obvious that text written in long lines is very hard to read on a screen. (Try reading Wikipedia in a full-screen window on 1920 pixels – you soon feel the need to resize the browser window)

Given its age, it is surprising (or rather disturbing?) that the full-window layout is still promoted in current web development environments, as the ASP.Net MVC default page layout is defined in Site.css as

.page
{
    width: 90%;
    margin-left: auto;
    margin-right: auto;
}

meaning 5% of the window width as margin on the left and right side of the content. (All other measures in the CSS file are given in pixels (px) or relative to font height (em)).

In contrast, sites such as WordPress or online newspapers use a fixed layout. Fixed layout makes it easier to arrange the page elements in a grid independent of the browser’s window size. (Note that while most WordPress templates use fixed layout, the admin pages are full-screen with fixed and variable columns)

As a reaction to both the question fixed-vs-variable and the increasing multitude of web-enabled devices from HD monitors (or bigger) to smartphones, the latest trend in web design is called Responsive or Elastic.

Responsive layout is typically implemented using CSS3 Media Queries which allows the definition of page and page elements styles based on properties of the output format. They make it possible for a browser supporting media queries to apply the CSS styles definition based on window width, so that a text may be layouted full-screen on small displays, and in columns or fixed-width on larger displays.

For more discussion on the topic, visit Smashing UX Design (using responsive layout itself) or the User Experience StackExchange site. CSSGrid.net also implements a 1140px responsive layout.

Enjoy resizing 😉

Grids, Paging and Infinite Scrolling

In Good Old ASP.Net, if you wanted to display a large data set, you chose a DataGrid or a GridView, connected it to a DataSet, and you got paging and sorting with a couple of clicks. If you wanted something fancy, like Ajax-style partial postbacks, there was the UpdatePanel. And if you wanted to achieve database-side paging and sorting (rather than C# = client-side), you needed to add some magic to get it to work.

Things change as we move on the ASP.Net MVC. The simplest way to display data is to have a foreach loop iterating a List<T> or array T[], and render the <tr>’s or <div>’s for each record. The MvcContrib project on CodePlex contains a Grid helper for every version of MVC. As of MVC 3, there is a WebGrid (blog, blog, blog) which also implements paging and sorting.

Server-side paging again is not the default functionality, but can be implemented with a couple lines of code, as illustrated on MSDN and SO. (The clarify the term “server-side”: it means that the database query returns only the records resulting from paging and sorting parameters. In case of a web application, even though running on a web server, the code that retrieves the database result is considered to be the client, as in “database client”)

But hey, the web moves on, and paging is out, and infinite scrolling is the new hype UI paradigm. Even though I already knew it from Google image search, Twitter, WordPress, or Facebook, I became aware that there was a term for it from the Coding Horror blog. Of course, the new approach has its drawbacks, and the blog also lists a couple of them, and not everybody likes it, at least not everywhere.

Infinite Scrolling also has some “funny” consequences, as stated in this comment:

Personally, I dislike the feature, but it does work better on some sites than others. Pinterest and Twitter use the technique appropriately. Facebook on the other hand, does not. Why do I say that? Have you tried to access the links they place at the very bottom of the page? It’s impossible when content is being continually added, pushing those links out of view time and time again.

Therefore, no footer on endless pages!

To implement infinite scrolling in ASP.Net MVC, there are already a couple of libraries available: Infinite Scroll on CodePlex (blog), the Endless Scroll (jquery archive, github, blog) and Infinite Scroll (web, github, sample,) jQuery Plugins, or custom jQuery code (sample, demos).

While researching this post, I also came across a hybrid of pagination and infinite scroll:

So here’s a hybrid solution that still separates content into pages and loads them when you scroll down but also allows you to skip around.

Page links are inserted between the content that’s been loaded and appended.

This solves multiple problems:

  • Separates content into pages so users know how “far” they are into your site and can find his/her way back to their favorite content by remembering the “page” they were last on.
  • No more linear flow, users can skip pages if they know the content they’re looking for is much further in.
  • If you skip pages they won’t load, saving time and bandwidth.
  • If you did skip pages, you can go back and load them by clicking on their page number.