design posts

I read a post recently of Dave Rupert lamenting that he can describe any digital interfaces as lists, details, or flows. This is, of course, an abstraction. Abstractions can be useful for reducing complexity and making things understandable. In code, they also can be used to reduce duplication and provide reason for limited responsibility, improving maintainability. But if everything is fit into a small number of buckets, it can certainly make it seem like there is a lack of diversity, a sameness to everything.

With any good abstraction, everything can fit into it with a certain level of mental effort. Some might be more willing to go further than others to make a given classification work. In code, too heavy abstraction can lead to a given abstraction trying to do too much, or conversely, functionality being limited to fit a simple concept of the abstraction.

I'm glad that Stir Trek has released videos of its 2016 talks, since I didn't l…

Every room has sun-light and moon-light. Hallways, stairwells, walkways, etc. probably just have moon-light. The sun-light would be the bright bulb(s) in the middle of the ceiling or by work areas to allow tasks to be performed. The moon-light is the much dimmer, low wattage option like a night-light, for moving about and other less visually precise activities. Continue reading post "Home Lighting: Sun-light, Moon-light"

I've been interested in the basic idea of responsive design since I first started into web development. Back then it was mainly limited to flexible widths that accommodated changing screen widths and font sizes. I experimented with that when development was just a hobby. Still, I found CSS2 and browser compatibility issues to greatly limit the flexibility. When starting to actually get paid as a developer, I went with what was already being done at the places I worked, which was pixel-perfect design. Sites had to work in old browsers and time was limited. Designs were flat images that were easy to cut up and use CSS to match exactly. I did play with some flexibility when I had more free time.

When responsive design became a thing, I thought it looked pretty awesome. It gave a lot more flexibility than what I had been playing with. Still, browser support was too bad for parts of it for me to use at work. I played with some aspects of it, adding a bit of flexibility here and there, but still kept mostly with the pixel perfect type design. When we eventually discussed it with my boss, he didn't like the idea, particularly for accommodating his designs and the browser support issues. I started a yet unfinished remake of my own site that allowed me to play much more, but didn't get very far towards a finished design.

The Site

Recently, my boss came up with a simple design for a simple site that he thought would be perfect for trying responsive techniques with, the annual report for the Gay Community Fund. It lent itself well to flexibility and him and the client were fine with graceful degradation / progressive enhancement. It consists of basically two layouts: the home page, with a gallery layout of boxes; and an internal layout with a heading, a possible image, a possible small image gallery, and a possible long list.

In building a website for a client, one usually builds clients, one usually builds a few mockups with different themes to give the client an idea of what the site will look like with one of a few options. They can tell the designer what changes they want, which can be made relatively easily to the mockup before the theme is actually built for the site.

The mockups are supposed to be quick and easy to build and modify, allowing designers to avoid dealing with all of the nuances of CSS and HTML at this early stage. Designers shouldn't be held to any limits at this point: They design what they think the site should look like, and figure out how to build it later.

Traditionally, this might have been done in Photoshop. The layout would later be cut up and positioned on the site with CSS. I did three mockups for the Stearns Homestead project in Photoshop. They were a pain, with maybe a hundred layers to handle two pages of the site for each mockup. Managing multiple elements of the same type is not easy there. Photoshop doesn't allow any easy management of multiple blocks of typography at once, so changes are difficult. Now that I'm not using school computers, I don't have access to a newer version of Photoshop, and none of my image editors have layer folders or some other useful features, which had helped me out a lot.

The Move

We finally bought the domain name and hosting account for Stearns, at stearnshomestead.com.  We were expecting them to want a .org due to their nonprofit status, but I guess they wanted the familiarity of the .com.  They have no company credit card, so Angela had to set up the account and will bill them for a check.  I don't know what they'll do in the future:  They'll probably have to have one of their members do a similar thing.

We moved our Wordpress install from its temporary location in a subfolder of one of Angela's sites to the root of the new site.  There was perhaps a bit of trouble moving the site, but once we figured it out, the install worked perfectly.  To move, we transferred from one site to the other via FTP all site files.  We then used PHPMyAdmin to export the site data as SQL and then import it to the new site (didn't have to use PHPMyAdmin for the new site, as the host has an import function in their control panel).  We then had to update the config file for Wordpress to reference the new database.  Finally, we had to change two URLs in the options table in the database.  Everything now works.

On Monday we met with Debbie to show off our design mockups.  Wednesday Debbie…

Over the past couple weeks we've been working on our mockups for the site desig…

After making our layout wireframes, we brainstormed some various thematic ideas…

An object that can have a wider range of uses, especially potential uses, shoul…