Lehrblogger

I’ve recently been using a Mac OS X tiling window manager named SizeUp. I had an idea about which I emailed the developer, and I thought it was worth sharing here too -

Hi,

I’ve dreamed about having a tiling window manager for years, and I was fortunate enough to see Alex Payne‘s tweet making a similar lament; I found SizeUp as a result. I’ve been using it for a week or two now, and I love it. Both on my 15″ MacBook Pro, and when the MBP plugged into my 30″ external display. Nicely done.

I have a suggestion though – I wish I had slightly more control over how windows were sized. I understand how it could be a user interface and/or Mac OS X nightmare to let users specify custom sizes or behavior for how windows snap to other windows. But at the same time, I’d love to be able to assign windows to a grid location occupying less than a quarter of my screen. For example, Adium chats don’t need that much screen real estate, even if iCal and Firefox do.

Rather than use the arrow keys to indicate location, what if you used the physical QWERTY keyboard locations of the letter keys? In it’s most simple form, W S A D could correspond to Up Down Left Right. But you can do more interesting things too, and split a screen into a six- or nine-rectangle grid using Q W E A S D or Q W E A S D Z X C. Any one of those keys would place a window in the respective corner of the grid, so [shortcut combination]+Q on a six rectangle grid would make the window use one sixth of the total size, with a width equal to a third of the screen’s width and a height equal to half of the screen’s height. If you wanted a larger window, you could press multiple adjacent letter keys simultaneously – [shortcut]+Q+A would make the window take the leftmost third of the screen, and [shortcut]+Q+W+E would have the same effect as the current [shortcut]+Up. It might make sense to use shortcut keys on the right side of the keyboard with these letters (shift+option seem to be sufficiently unused in this context), or you could use a different set of letters and keep the shortcut keys where they were. In the SizeUp Preferences, users could even specify the number of rows and columns in the grid they wanted to use and the keys they wanted to assign to each screen location.

(This idea is somewhat reminiscent of a still-incomplete project I was doing a few months ago: a Javascript portfolio website that used the keyboard for navigation, had a representation of the keyboard on the screen, had all content exist on that visual representation of a keyboard but at different zoom levels, and used the physical keyboard keys and spacebar to zoom in and out on the on-screen keyboard to view content at different levels in the hierarchy. There are a few blog posts about it here.)

Sorry that was so long-winded, and please email me if you want to discuss further or need me to clarify.

Keep up the good work!

Best,
Steven Lehrburger

cross-posted at textonic.org
previously: Design for UNICEF – Detextive*, Mobile Tech for Social Change Barcamp, Design for UNICEF – RapidSMS and Mechanical Turk

Textonic.org is now live!

Recognizing that Textonic was a larger project than I was going to be able to finish in my free time over the summer (or that my group was going to be able to finish in our collective free time), I decided that the project would benefit from a more formal web presence than a handful of blog posts and a GitHub page. I registered a domain, set up WordPress, presented what we had accomplished, laid out what there is to be done, and tried to create a place where people could express their interest in getting involved.

The Conversation page on the new site is of particular interest. I’m using a Twitter search for the term ‘textonic’ as a sort of guestbook or message board. People who find the site and are interested can look to see who else has been there as well as when they expressed interest. Twitter itself can serve as a way for them to get in touch. The intransient* and public (since all of a user’s followers will also see the tweets) nature of these expressions of interest will help to catalyze the formation of a community around the project.

Credit for this idea goes to @n8han (who writes the blog Coderspiel) – I first saw it on his site for Databinder Dispatch. In addition, recent ITP graduate @joshbg2k created something similar for his Überbaster project.

*Note that Twitter’s search API only exposes that last ~3 months of tweets, so at some point I’ll need to archive the messages so that the entire conversation history is displayed.

I was awarded a student scholarship to attend the annual Apple Worldwide Developer Conference, so I’ll be flying to San Francisco in June. According to the website, the event “provides developers and IT professionals with in-depth technical information and hands-on learning about the powerful technologies in iPhone OS and Mac OS X from the Apple engineers who created them.” Many of the planned sessions sound interesting, and I’m also looking forward to the Apple Design Awards. I’ll probably spend the next month working on Meetapp (rather than Delvicious) so that I’m better prepared for the iPhone development labs.

I’m also planning to attend the Scala Lift Off on June 6th, a conference for developers using Scala and the associated web framework Lift. I hope to have more time to talk with some of the people who attended the Scala BASE meeting at which I presented my TwiTerra project in January. Martin Odersky, the creator of Scala, will also be speaking, and my friend Jorge Ortiz plans to attend as well.

I’m excited to go to both events and to visit other friends in California, so I’ll be sure to post about them again.

previously: project description, initial progress

David Nolen’s Little Computers class is now over, and I’ve made substantial progress this semester on Meetapp, the iPhone application I have been building for users of Meetup.com. Currently, it will fetch a list of a user’s groups from the API at that user’s request, make secondary API requests to fetch the events associated with each of those groups, and then display all of those events (i.e. all of those events that a user might be attending) in a table. It will also filter that table to show only those events that the user is organizing (rather than simply attending), and the user can drill down for more detailed information about both types of events. So far, I have -

• built a straightforward application that uses a navigation controller, a toolbar, and some tables to organize the information.
• implemented HTTP communication with the Meetup API using stored credentials for the user.
• created data structures for managing information about a user’s groups and events.
• designed and re-designed the interface so that it was simpler, cleaner, and better-suited for the functionality I was actually implementing.

The app has some use in it’s current form, but there’s a lot I still want to do before it’s ready to be posted for the public in Apple’s App Store.

The most recent code is on GitHub, and please feel free to contact me with questions about my progress so far or future plans. I hope to continue the project later this summer, but Delvicious will be my prioritized side-project, at least for the time being. I’m looking forward to watching the lectures from Stanford’s iPhone class to brush up when I jump back in to Objective-C in a couple of months.

project page here with overview and previous posts

http://delv-icio-us.appspot.com/

A very alpha version of Delvicious is live at the above link! You can currently sign in with your Delicious account (or use one of the ones I posted towards the bottom of the GitHub page), tell it to fetch all of your bookmarks (making a copy of the URLs in Google’s datastore), and then perform searches of those pages using a Google Custom Search Engine that is created on the fly* from XML files that are automatically generated and served by App Engine. I’ve had a little trouble getting the CSE’s to work the first time a user tries to use the search box, and I suspect that the search engines are not immediately ready for use after their (implicit) creation (which I think happens when the user first tries to do a search). One of the first of many next steps is to find a way to initialize that search engine automatically and inform the user (via email) when it is ready. If it’s not working for you, wait a little while and try again later.

There’s a lot of other functionality I want to add, and other next steps include:

• automatic updating of a user’s Delicious bookmarks, modifying only the necessary entries in the Datastore to reflect the changes on Delicious
• leveraging Delicious tags to improve search results – both by using them as refinements, and by being sure to return results that have the tag you are searching for (I’d love to have support for a “tag:tagname” operator in the search box)
• an option to leverage the number of other users on Delicious who have bookmarked a site to improve search results, since presumably heavily bookmarked pages are more useful
• Delicious results optionally displayed side-by-side with the Google results, both for comparison, and to make sure that all useful results are found (currently Delicious finds things that Google doesn’t) (I might use the Beautiful Soup HTML parser to scrape the results from the Delicious search pages since they aren’t exposed by the API)
• improve authentication with Delicious
• explore ways to support the searching of private bookmarks (but I’m not sure this is possible, since Google needs public XML files to create the search engines)
• do the graphic design for the various pages

I will continue to work on the project over the summer, and I hope to launch an initial version within the next month or two.

* I did this using Linked Custom Search Engines, and it’s worth noting that this was not the original plan. I had intended to ask users to authenticate with both Google and Delicious, and use the Google authentication for the creation of and interaction with CSE’s using HTTP requests. CSE’s only support Client Login authentication, however, which is intended for desktop/mobile applications and requires users to manually type in their usernames and passwords. I knew that I would not be able to convince users to give me their unencrypted Google login information (nor did I really want to possess it), so, without the ability to authenticate Google users on a google.com Google sign-in page, I was going to need an alternate solution.