Integration and Degradation

Software projects start modestly enough — a general problem statement that we've set out to solve. But then they grow. And grow. Either the problem changes, or our initial assumptions about how to solve it were so flawed that we just that far off in guessing how difficult the problem actually was. How prepared we were with our existing domain knowledge. How difficult it would be to acquire people with the right skills. Its in these situations that we take a software project, experiencing a deficiency of some sort, and start integrating other software components. It is through this exercise of integration that we're introducing unintended consequences of bringing on new software components.

Desktop Environments and File Uploads

I remember when I used to see web applications with forms that had up to ten file fields, you know, in case you wanted to be more productive and submit many files in the same post. I smile when I think about those forms, not just because they looked funny, what with the repeating vertically-stacked file inputs, but also because of the whole file upload concept. Beyond sharing images on social networks, the practical use of user-generated files on the web has it's limitations. Think about where most of our tools are located. We're generally not screaming for new desktop applications, unless we're part of a particular crowd — like developers, graphic designers, hardcore gamers. We need desktop applications for these purposes, and these applications deal with files. But the vast majority of internet use isn't to this degree of specialization. What use does the general internet population have for file?

Library Knowledge Depth

There are no small libraries, not anymore. Actually, come to think of it, there are small libraries, they just aren't used by the application developer these days because the tools employed tend to be all-encompassing. That's the attempt anyway, and with valid reason too — I'm not going to like using toolkit X because I can't do Y. To do Y, I need toolkit Z. The less variability in the dependencies of my application, the happier I am as a developer. This over-arching attitude of mammoth libraries, however, creates a knowledge problem. The library tries to solve so many problems, that its size grows beyond what can fit in any one developer's head.

Dashboard Roles

"Dashboard" is an interesting name for a UI component, one floated in any discussion about user interfaces today. The trouble I have in understanding dashboards is the same trouble I have in understanding "cloud" — what do they do? Is there a generic version of the dashboard that I could take and apply to the UI I'm working on right this moment? Or, does "dashboard" simply capture the idea that important user information needs to be available to the user, at all times? Still, we're left wondering how to go about providing this dashboard component for application X because we don't necessarily know what information is important to our users, and what information needs to be monitored, collected, and presented to the user in real time.

Navigation and Object URIs

How do we go about designing a web application that does well with both the navigational structure presented to the user, and the URI format used to traverse the application? They really are distinct problems, are they not? If so, I find that I've artificially blended the two concepts together. Maybe that's because, as a user, I've unintentionally joined the two ideas. After all, they both play a role in the same job. They take the user from one place to another. One from presents a graphical layout to the user, often with styled elements using some kind of grid layout. The other, is just a string destined for the browser address bar. An action in the navigational menu often means a change in the URI. The change is triggered from the user interface, and I would think that this is the expected pattern of behavior, as opposed to the user constantly typing in the desired location — unless the menu is really that bad.