Lehrblogger

I set up a local MySQL database to store the information about the keys, and I made two web pages to interact with that database. The first displays a table of the current contents of the database (currently, what text is associated with each key) and the second allows you to add, update, or delete database entries for the keys.

Much of the work involved was learning how to use PHP and MySQL , and the functionality I implemented is effectively just a tiny subset of what you might find in phpMyAdmin. It will be necessary later, however, for dynamically re-generating the HTML page for the actual keyboard site whenever I update the content; this will allow search engines to index the content in their crawls. In addition, I can also generate the images of the keys (based on their content) that will be used to create a smooth key resizing effect.

I’m not going to create a web-hosted database and upload the files and get everything working for this update, but the new files can be viewed on github: http://github.com/lehrblogger/keyboard-portfolio/

recently: current upload
previously: initial idea, implementation experiments, early progress

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/nyu/classes/fall08/ajax/hw6/part2.

I started to think in detail with David about how I was going to implement various parts of the site, and I set up Apache and a MySQL database on my local machine to facilitate testing. All of the page content will be managed through interaction with the database (possibly through a content management page). Saving this page will automatically generate new Javascript and HTML for search engines to crawl and index.

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.

The automatic generation of the HTML and Javascript will be a challenge to get working, but they will make it much easier to manage the site. It is likely that the best way to get the text resizing to work will be to replace that text with an identical-looking image, resize the image, and then replace it with text at the new zoom level (or not, for smaller zoom levels). Those images would need to be automatically generated from the text saved to the database via the CMS, and (with David’s guidance) I’ve started to look into using Cairo for doing this on a server.

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.

I made substantial progress on the main layout and animation for my keyboard portfolio. The keyboard is built dynamically from what is now an array of letters, and I used the MooTools tween/morphing functionality to handle the animation. Tweening of both the size and location of keys on the full keyboard at 24 fps seems to be more than my browser can handle, however, and I need to figure out a way to improve performance. There are three versions below – the first is without any tweening, the second is with tweening for only a part of the keyboard, and the third is with tweening for the whole keyboard.

In all versions, clicking on or typing a letter will zoom in on that letter, and spacebar zooms out keeping that letter in the upper left. I’m using Firefox 3.0.3 to view these, and I’m not sure if other browsers will work.

(It was much trickier than I expected to get the keys to change and move correctly, so I didn’t have time to modify the Flickr/GoogleMaps/YouTube/Twitter examples – I will later this week.)

HW6 Part 1 (no tweens): http://lehrblogger.com/nyu/classes/fall08/ajax/hw6/part1_notweens
HW6 Part 1 (partial keyboard): http://lehrblogger.com/nyu/classes/fall08/ajax/hw6/part1_partial
HW6 Part 1 (all): http://lehrblogger.com/nyu/classes/fall08/ajax/hw6/part1_all/
HW6 Part 2: http://lehrblogger.com/nyu/classes/fall08/ajax/hw6/part2/

I used the first few assignments for experimentation with the canvas tag to begin to think about the implementation of my keyboard project. For the first part, I used some Javascript and CSS to draw out rows of boxes for a basic keyboard layout. The second example draws and then resizes a simple rectangle within a canvas tag using scale() and translate(), but it should work for any content.

I initially had (in HW5 Part 2a) some question about whether I should use one canvas tag for the entire keyboard or multiple canvas tags for each key. I was thinking that it makes much more sense to use one for the whole keyboard, since everything will be scaling and translating at once (perhaps with photos off the screen not switching to a larger version? hmm). I started to run into problems, however, when I began to look into displaying text on a canvas tag. There are a few alternatives, and maybe something that doesn’t work in Firefox yet, but all seem to involve drawing the actual typecface vectors manually. This might work for now, but it would be nice to have selectable text on the pages, and I’m worried about S(earch)E(ngine)O(ptimization) later on, so I decided to look for other ways to make it work.

Instead, I continued to move forward with representing the keys as div tags (in HW5 Part 2b). I made a fair amount of progress displaying the keyboard, adding key listeners, and moving keys around appropriately. Multiple sizes are almost, but not quite, working, and once that is done I can work on tweens. I still need the text to resize smoothly though, and might be able to get something based off of this idea to work well, but I’m skeptical. Does anyone know of any other solutions? Maybe generating an image for each text field, and replacing the text with that when it’s being resized, and shrinking the image, and then replacing the image with text again when it’s done resizing?

More on that project later this week — the last assignment here was to modify the ‘animals’ example that he presented in class. It was the first example we had seen of a full web project – using HTML, CSS, and Javascript, as well as PHP and MySQL to pull information from a database. I had an absurd amount of trouble getting it to work on either the Dreamhost or the ITP servers, but I finally resolved the various issues. Getting the naming to work was much more manageable, but I learned the basics of using a database in the process. (The information for the animals is stored in a single database, so all visitors to the site are viewing and modifying the same animals – refresh the page to see any changes made by others.)

Note that I’ve noticed these are acting sporadically in browsers other than Firefox 3+, and I’ll try to figure out the browser compatibility issues this week.

HW4 Part 1: http://lehrblogger.com/nyu/classes/fall08/ajax/hw4/part1/
HW5 Parts 1 and 3: http://lehrblogger.com/nyu/classes/fall08/ajax/hw5/parts1and3/
HW5 Part 2a: http://lehrblogger.com/nyu/classes/fall08/ajax/hw5/part2a/
HW5 Part 2b: http://lehrblogger.com/nyu/classes/fall08/ajax/hw5/part2b/
HW5 Part 4: http://lehrblogger.com/nyu/classes/fall08/ajax/hw5/part4/

HW3 Part 2b: http://lehrblogger.com/nyu/classes/fall08/ajax/hw3/part2b
HW4 Part 2: http://lehrblogger.com/nyu/classes/fall08/ajax/hw4/part2/popularity_check.user.js
HW4 Part 3: http://lehrblogger.com/?p=61 (link to previous post)

(Note the new directory structure – I’ll transfer the files from previous posts when I get the chance.)