I don't care for UI code. I don't care where the pixels end up or how round a button is.
Case in point, I just added a column to a table. The problem: the column isn't wide enough to hold the data it displays, so the data runs out of the column and into the next one, overwriting the text there. Simple problem. Simple solution? No. It was easy enough to add a style element to the column making it wider. But now the column header didn't line up with the column. I added the same style element to the header, but it was completely ignored. In fact, nothing I could think of would make the column header simply be wider than it was. There were 12 columns, and each header took 1/12th of the space. That was written in stone.
Well, almost. I made there be 13 columns, and set that one particular header to span 2 columns. I had to do the same to the data and make it span 2 columns as well. It does not look good, but that particular column is now wide enough to hold the data, and the header lines up above the data like it should. Unfortunately, each of the other columns are just that much narrower to spoil the layout. There are some columns that would naturally be nice and narrow and give me lots of extra room to play with, but no, there are now 13 columns, each taking 1/13th of the space, except for one that's twice as wide.
This is why I don't like UI. Why does the table data pay attention to the "width" directive and the table header ignore it completely? I don't know. Will anyone complain that my "solution" is ugly? You bet. I even think it is ugly. I've already wasted enough thought and energy trying to make it prettier, but to no avail.
2 comments:
Allow columns to be displayed or not displayed at the user's choice. Also, have an option for the page to be downloaded in CSV or ODT or OOXML format. (Excel doesn't care what the extension is, so you can write CSV into a downloaded file named foo.xlsx.)
These are all great ideas, but the code was written in Angular with the only intended option of a big HTML table. Abstracting this out so that it could handle different formats would have required major surgery if not a total rewrite, and that was out of scope.
Unfortunately, that is one of the problems of the Agile approach to software. Incremental and superficial changes are highly favored over large and fundamental ones, so tasks such as "take a day and add one column to a table" are assigned rather than "take several days and make columns displayed as per user choice", and tasks such as "take a couple of weeks and make the display agnostic about the underlying output format" are completely unthinkable. It is especially hard to persuade a customer that you did anything useful if the end result is a change to the architecture that adds flexibility to your display and output options, but you don't radically change the actual display.
Another problem of Agile is that it involves the customer too much. Customers are bad at determining how software can meet their overall needs. In this case, they needed a table of "all relevant, essential information", but couldn't articulate what "relevant" and "essential" meant to them, so instead we got individual requests for more and more columns when they decided that the current column set wasn't quite adequate. And they were happy and satisfied with the table growing beyond the bounds of the screen. They "needed" more columns, and if they didn't fit, well, that was a natural consequence of the need for more columns. The notion of a display with dynamic columns they could select didn't seem worthwhile back when you could easily display all the columns, and adding the capability when there is a scroll bar to view the extra columns seems overkill to them. Eventually, they'll realize how much of a kludge this is and perhaps request dynamic columns. But until then, other tasks are going to take priority.
Post a Comment