Clone this wiki locally
Spaz for AIR, in its current incarnation, has grown very organically as I’ve learned the best ways of doing things. A lot of code was hacked in rather than being thought out. This has lead to a web of intertconnected, tightly coupled components and a fair bit of unnecessary repetition. It makes it harder to make significant changes because the data access stuff expects the UI to work in a particular way, and vice-versa.
Working on Spaz Mobile has proven to my satisfaction that the speed with which I can create a better, more extensible, cleaner codebase. SM is a total rewrite from the ground-up, something that was basically necessary due to the tight coupling of the current Spaz codebase. While I’ve been working on it for about 3 1/2 months, I’d say that 70% of that time has been learning and working with device’s UI framework.
The base of Spaz mk2 will be SpazCore, a collection of components that intends to be a base for creating applications like Spaz – primarily Spaz itself, but you could certainly build other, similar apps on top of it. SpazCore is targeted for Titanium, AIR and webOS. You can read a lot more about SpazCore on the SpazCore Wiki.
SpazCore doesn’t dictate how the application is structured, though, (except that it uses custom events extensively). That’s up to the app itself. In this case, Spaz mk2 should implement a form of MVC. Specific to this implementation, I think it should have “smart” views and models, and relatively light controllers. Data logic is handled in the model, UI logic is handled in the View, and the Controller would simply intercept user (or other outside) input, and delegate actions to the Model and/or View. Generally I think the Model and View should communicate directly when possible, and preferably via events.
Spaz mk2 UI
- We shouldn’t lose the tall, vertically-focused single-list style of Spaz. I don’t like the size of things like Tweetdeck. Spaz should be focused on creating a strong experience for the average user, and most of them don’t need a wall of data.
That being said, there are a number of “power user” features I want in Spaz.
The Primary Window
When a user starts Spaz, they should get a single “primary” window that includes the following sections:
- Combined Following/Replies/DMs
- Combined Sent
Note that the primary window should not initially display a posting textbox. There should be a UI button to bring up a posting dialog, and a corresponding keyboard shortcut. We may consider an option to display a posting box at the top or bottom of the primary window, however, if users are in favor of it.
Each section should refresh automatically and inform the user of new results via a notification (using the Titanium notification system, so Growl/libnotify/Snarl). Clicking on that notification should make that section active.
In addition, users should be able to define custom notifications. These notifications would trigger when a message matches a set of chosen properties. Properties should include:
- source (followers timeline, public timeline, replies, direct messages)
- a regex match on message properties (user, message text, source)
Clicking on a custom notification should bring the source section to the fore and scroll to the matched message.
The User should be able to dynamically add additional search sections. Queries should be save-able, and recallable quickly from a menu to load into any given search section.
In addition, the user should be able to define custom sections by choosing the following properties:
- source (public timeline, search query, followers timeline, replies, direct messages)
- whitelist or blacklist regex filters on properties (user, message text, posting source)
- It would probably be useful to make it easy to define a group of users, as that will surely be a primary use of custom sections
Custom sections based on “permanent” sources like the followerstimeline, replies and dms should NOT independently refresh, but instead grab data when the standard refresh happens.
Ignoring a user
There should be a special filter option to block any messages from all sections, across the board. This would be purely handled by the client, and wouldn’t involve API methods like unfollow or block.
Handling all these sections
A standard tabbed interface is going to break down quickly UX-wise with all these sections, especially considering “tall and thin” layout we’re aiming for. One possibility would be to just remove the tabs, and instead have arrows to natigate through the array of sections. Keyboard shortcuts would let you jump to the permanent sections quickly, and a dropdown/popup menu that lists all sections might be a good addition.
Rate limits could be a concern here too, especially with a lot of searches.
Mutiple account support
First off, Spaz mk2 should use OAuth. We should avoid basic auth as it will likely be restricted more down the road, and/or the new cool stuff will only be available to OAuth-authenticating clients.
Primary management of accounts would happen inside Preferences, with a list of accounts and [ADD] and [DEL] buttons. Clicking on the [ADD] button would bring up some kind of prompt, but it’s not clear exactly what it would contain until the workflow is better defined. There should probably be a faster way of simply creating a new instance, which would prompt the user to start the authorization process, without entering prefs.
I imagine the OAuth workflow working like this: user indicates they want to add an account, and receive a prompt explaining that they need to log-in via a browser and grant permission to Spaz. User clicks [OK] and a new window is opened by Spaz with the oauth request URL & request token (making sure to force login as described here). Data is returned to Spaz with the access token, and Spaz retrieves the user’s data, adding the account to the DB with the username and access token. The list of accounts is then updated to reflect the account DB.
Each active account would be represented by a primary window. A user should not be able to have two primary windows logged-in to the same account, as that would likely run over rate limits quickly.