I’ve been having some issues with browsers other than Firefox, and I think most of them were stemming from my use of console.log for debugging in Firebug. David Nolen (the course instructor) posted a solution to this issue, and all past projects should now be working. I also fixed a few other Safari-specific issues in the keyboard project.
I decided to use Git, a popular version control system, for the continuation of the project. This will allow me to keep track of changes and progress in a sane and flexible way. I’m also going to use GitHub, a collaborative code hosting service, to make it easier for others to comment on and contribute to the project as it moves forward. You can visit the GitHub repository of the project here: http://github.com/lehrblogger/keyboard-portfolio.
I began to explore the powerful Flickr API, and plan to use it as the source of the photos for the portfolio. Provided that it proves to be fast enough, it should simplify image uploading, facilitate various file sizes, and create a unified place for comments. Image names and captions on Flickr will also be displayed on the website. Image categories and projects will be tracked using tags. (Each category and tag will probably have a ‘slug’ in the database (more on that later), and the tag should use that slug.) I’ve used ‘category2’, project1’ and ‘image1’ in this example, which just pulls a single image from Flickr using the API — <http://lehrblogger.com/projects/fall08/ajax/hw6/part2.
Each standard keyboard key will always have an entry in the database, and this won’t be changeable from the CMS (content management system). Each key will have one of four possible modes — category, project, blank, and hidden — and other available table entries will depend on which type of key. Most punctuation keys will be hidden, but I will provide support for them in case I need the space for additional content later. Blank keys will have no other data associated with them, and will likely be greyed out on the site. Project keys will have the most associated data — the project will need a title, descriptive text (with limited HTML formatting), and some number of associated Flickr photos. Category keys will have a category name but no other content.
Note that there will be no difference in how each of the latter two types of keys behave. At the second level of zoom, the focused key and the surrounding keys will all be visible. At the third level of zoom, only the primary key will be visible. At the fourth level of zoom, for viewing the images, the interaction is handled through the number keys (1,2,3,4,5,6,7,8,9,0 — for up to ten images), and these won’t do anything on keys without images. A user can press a project key from the top level, but that user would need to press it again to be able to read it.
That might be the trickiest part of this whole thing, but if everything works well together it will be really cool. I’m not quite sure that I’ve been able to fully convey with clarity my idea of melding content and interface, and I’m excited to have a working example.