Visual design is more art than science still, and even when it can be made fairly rigorous finding people who not only can make a good design but also articulate its logic in a formalizable way is well-nigh impossible; they're out there, but it's a really rare skillset.
What you'd encounter if you started going down the route of implementing something like that in magic ink is that it's easy to make mockups in photoshop, where you have control over design and content-to-display; once you get into the real world you have a world of edge cases to deal with.
On an individual level these are often easy to solve, once you're aware of their existence, but the richer the visual display the more overwhelming the edge cases come in.
Here's a trivial example from that widget: along the left edge you have columns of "fare types" (internet special, refundable, etc.) that have the respective price quotes at the same horizontal level as the itinerary; after the lower left corner they wrap down-and-to-the-right and have definitions of the fare types.
For a single purpose -- airfare -- with a static set of flight types this display system could be made to work, but here's some things to consider:
- you notice how the # of flight types is exactly the right amount to match the height of the price quote section in the lower right corner? how pretty would this layout look if it was a few types too short or too long? There's stuff you could do -- adjust relative font sizes, etc. -- but doing that in an automatic fashion is tricky and invites more edge cases to emerge, and what's worse it might screw with the visual hierarchy (b/c human visual perception of relative font sizes isn't all that precise)
- you notice how the definitions of flight types are all short enough to fit in the available space? what visual idiom ought to be used if there's too much text (there's lots you could opt to do, but you have to pick something and make it work)?
- what is the visual idiom when the # of flights available on that day is just ridiculous (like the east coast "shuttles" which fly on the hour, every hour)? unless you have a giant screen you're going to have to scroll in some fashion, but what kind of scrolling (only the flight panels, the entire screen, etc.?)
These "problems" aren't so much hard algorithmic problems as just decisions that have to be made, and then stuff that has to be made to work.
For limited use -- where most of the requirements and, more importantly, most of the extreme ranges -- are known in advance, it's possible to craft something like this, but to make a general, reusable component for something like this is far harder than it seems at first.
Automating aesthetics will happen at some point, but it's tricky.
Visual design is more art than science still, and even when it can be made fairly rigorous finding people who not only can make a good design but also articulate its logic in a formalizable way is well-nigh impossible; they're out there, but it's a really rare skillset.
What you'd encounter if you started going down the route of implementing something like that in magic ink is that it's easy to make mockups in photoshop, where you have control over design and content-to-display; once you get into the real world you have a world of edge cases to deal with.
On an individual level these are often easy to solve, once you're aware of their existence, but the richer the visual display the more overwhelming the edge cases come in.
Here's a trivial example from that widget: along the left edge you have columns of "fare types" (internet special, refundable, etc.) that have the respective price quotes at the same horizontal level as the itinerary; after the lower left corner they wrap down-and-to-the-right and have definitions of the fare types.
For a single purpose -- airfare -- with a static set of flight types this display system could be made to work, but here's some things to consider:
- you notice how the # of flight types is exactly the right amount to match the height of the price quote section in the lower right corner? how pretty would this layout look if it was a few types too short or too long? There's stuff you could do -- adjust relative font sizes, etc. -- but doing that in an automatic fashion is tricky and invites more edge cases to emerge, and what's worse it might screw with the visual hierarchy (b/c human visual perception of relative font sizes isn't all that precise)
- you notice how the definitions of flight types are all short enough to fit in the available space? what visual idiom ought to be used if there's too much text (there's lots you could opt to do, but you have to pick something and make it work)?
- what is the visual idiom when the # of flights available on that day is just ridiculous (like the east coast "shuttles" which fly on the hour, every hour)? unless you have a giant screen you're going to have to scroll in some fashion, but what kind of scrolling (only the flight panels, the entire screen, etc.?)
These "problems" aren't so much hard algorithmic problems as just decisions that have to be made, and then stuff that has to be made to work.
For limited use -- where most of the requirements and, more importantly, most of the extreme ranges -- are known in advance, it's possible to craft something like this, but to make a general, reusable component for something like this is far harder than it seems at first.
Automating aesthetics will happen at some point, but it's tricky.