Posts tagged design
I came across Rahul Mahtani and Yofred Moik’s conceptual design of a Google Mail Envelope a few days ago and was… instantly captivated. I’m not sure if it’s just the aesthetics of a design on the envelope in general, the way it hearkens back to an old school airmail envelope, or the conceptual neatness of the route between the two addresses. I just know that I love it and I want it.
So, I spent some time making a version of it.
Right now, my implementation is very much hacked together (I was teaching myself the Google Maps API as I went — it’s not hard, but it’s not familiar vocabulary, yet — I have a few other projects that will get me more expert soon, I hope). The things to know are:
- Change the addresses and the map will (should) update to reflect the new information.
- The first line of the address is removed on the assumption that it’s a name and not part of the address (and users are cruelly constrained to 3-line addresses right now).
- The resulting envelope template is pretty much exactly a full-bleed letter-size page. Which means that printing it is a hassle.
- I strongly suspect that there should be a dampening-down of the colors on the map so that the USPS can automatically scan the right information easily. My recollection from constructing bulk mailings a few years back is that the address just needs to have a bit of white space around it, but having a mess of other geographic information scattered nearby may not be helpful…
- The snazzy orientation of the address infoWindows on the original design hasn’t happened yet. I think I have an idea of how to do it with some CSS (they won’t be “real” infoWindows), but haven’t taken the time to fiddle with it yet.
- There’s something hinky with the borders of the side-flaps due to the not-yet-standard border-radius CSS.
More to come as way opens.
As part of my education technology role at my school, I am a member of our high school “Laptop Leaders” group. A few weeks ago, at the end of our first quarter, the Laptop Leaders were asked to document the work they were doing, to create a shared resource, both for themselves and for other teachers. Ultimately, this is preparation for more large-scale adoption of laptops and technology in general as teaching tools in the high school.
The teachers in this Laptop Leaders group were selected last spring, so I joined the group late, at the beginning of the school year and had, really, only a sketchy plan for what I would be working on. The outline (lightly revised) is below. My intention is to share my various write-ups related to this process in this space.
I’m working with students to develop a class wiki as a collaborative information source, with students contributing class notes, screencasts and other updates and expansions on course content.
I’m working with students to use the class blog as a publication platform for ideas/questions relevant to the greater community in their discipline (e.g. develop [my class] blog into a discussion of [media and design] and related ideas in the outside world).
I’m working with faculty (and students) to use social bookmarking tools (specifically Diigo) to create dynamic and annotated resources for each other (and for and by students).
I’m working with faculty and students to develop personal learning networks that tie together all of these Web 2.0 tools to create an online identity and a group of “fellow travelers” studying and exploring the same area. In students’ case, we’re working on this as a class (blogging), but for faculty tools like Twitter (and personal blogs) may also be useful. Also looking at other sharing sites (e.g. Flickr) for use as collaborative tools.
In the interests of sharing, when I was at my last school, I sat down and created an iusethis.com profile of the handy applications that I use day-to-day. I’ve added this to my profile [on the school wiki], along with a (slowly growing) list of tools that I’ve built for special purposes around school.
Updated November 22, 2009: I should mention that I have Bowdler-ized some of these posts to protect (at least a little), the identities of my students. When posted to our school wiki, there are a number of links to examples. If you pop me an email or a comment and identify yourself, I’m happy to share these examples. Just trying to do some due diligence with regard to my students’ privacy.
I’m in the throes of reworking my Introduction to Computer Science course for the coming fall. I was thoroughly dissatisfied with how I taught the course this year: I’m at the stage of teaching where I know how I want it to go, but can’t always make it happen. Of course, this may not be a stage, but could, depressingly, be the existence of a grown-up.
I have divided the course into three broad areas that I think are most important to cover: computer science (as a discipline: concepts like variable scope, Boolean logic, object-oriented design, and so on), programming in Java (concrete details like how a for loop works or how to declare a class) and design and implementation. Design and implementation is actually really the core of my fascination with this course: how do you teach problem solving? And how do you get students to apply those skills.
In doing this, I’m plowing through a lot of articles.
- Jason Tselentis does a great job of identifying the challenge (with a special focus on graphic design problem solving and software, to be honest), although what he’s really talking about has more to do with my general challenge in academic computing: developing able and fearless tinkerers.
- Anthony Cowling goes into much deeper, and more software specific, detail, pushing the idea not just of scaffolded design education, but helping students learn to assess the quality of design (subscription).
- Phillip Greenspun tackles not just the problems of teaching problem solving and design, but discusses MIT course 6.916, on developing web applications with an eye towards developing broadly competent and self-reliant alumni. Again, his basic ethos flows directly into my primary concern in any approach to academic computing: are we teaching a shamanistic approach to computers (“follow these specific steps in this order and it works.”) or are we supporting the development of true independent learners who can sit down and “just figure it out.” Greenspun and I are in the same camp, supporting the latter option.
- Gary Pollice wrote a great article describing his introductory software engineering class — which touches not just on design, but on teamwork. Again, he’s preaching somewhat to the choir as I read about his students working on semester-long courses with real clients.
Of course, the challenge is now to boil down all these design concepts into something that is useful not in a first-year computer science or software engineering undergraduate course, but in a first-semester high school course. How much do my students really need to know about UML, CRC cards, flow charts, eXtreme Programming, incremental development, rapid prototyping, functional requirements and use cases? Not a whole damn lot. Mostly, I want them to learn to enjoy the process of rigorous problem solving as manifest in learning to program a computer.
But I’d certainly like them to not be starting down the garden path of bad habits based on ill-considered pedagogical frameworks.
Ah, for the days of Pascal as a first programming language!
…you know it: about how those who can do and those who can’t teach.
I just registered a bunch of us to go an Edward Tufte class next month, and to do it I had to wade through poorly designed invitation (difficult to find key information in a morass of identically sized and weighted typeface) and a poorly designed web site (similar difficulties). Perhaps my favorite part was the form designed to be printed out (how 1998!) that printed out with none of the necessary information. I could probably have tweaked some print settings — but if the default settings are good enough for everyone else, by god they’re good enough for me!
I just saw two articles with in the space of ten minutes: one on the substantial/frustrating/obscenity-inducing work behind building web sites compatible with different web browsers (and, because A List Apart is so cool, another matching article on the same topic) and another on converting API interface hooks into a filesystem.
I passionately believe that the development approach of the major browser developers has been sloppy at best and at worst an example of poor design and implementation. Browser releases that break existing web sites (or that are flagrantly incompatible with either standards or other major browsers) are not supportive of an open and free flow of information (and design).
That said, the article on the Accessibility Filesystem is a fascinating example of a piece of software that is so well-designed and open that it is compatible with innovative, unexpected and bizarrely wonderful new applications. Being able to browse the interface components of my running applications as though it were a filesystem? How cool is that!?! And check out the other Fuse plugins. It’s a neat technology with a lot of interesting applications in search, organization and possibly even data visualization.We need more Fuse and less browser skirmishing.