Twitter reader and personal manager

TweeTabs as a project

The following notes are extracted from a "flash" presentation of the idea behind TweeTabs at `MontrealPython 6` http://montrealpython.org/. I use them as a reminder, and remove items below as they get documented or integrated elsewhere.



1   Main motivations

  • Twitter appealing nature
    • This is about following, not about getting followers
    • Lots of good information, yet lot of noise too
  • Sparing one's own time
    • Current readers are not user-efficient enough
    • Not really set for high volume or high density
  • Getting Twitter and social networks experience

2   The TweeTabs idea

Tabs of strips

  • Much familiar, but under-exploited
    • For both presentation and contents
    • Pushing on the paradigm
  • Container (chrome) for an application (engine)
  • Typed contents (all strips of the same type)
    • Attributes
    • User flags (for grouping or otherwise)
    • Text (might be another attribute)
    • Other nested tabs
    • Streams
  • A way for an engine
    • Each tab represents dynamic, typed contents
    • Hidden tabs may convey computation
  • A way to a user interface
    • Scrollable (smoothly)
    • Drag and drop triggering drop-down menus
    • Vertical (a few horizontal) and resizeable
    • Maybe transferable between windows
  • A way to configuration
    • Handling many identities (v.g. icule, iculefr)
    • Management of Twitter API rate limiting
    • Internationalization
      • Maybe text spelling and text translation
    • Id management (users, statuses)
  • A way for an help system
    • A self-generated stream of strips
    • But contextual tooltips
  • This is the central concept (hence TweeTabs)

Built-in tabs

  • TweeTabs configuration
  • Timelines (public, or per user)
  • Following (ing)
  • Followers (ers)
  • Single user profiles
  • Twitter searches

Tab management

  • Cloning and copying
  • Auto-hide operands
  • On the tab slip
    • Left-click to select and pop (if not fully visible)
    • Right-click on the tab slip (refresh, rename, delete, hide)
    • Left-drag to another tab (reorganise, nest, merge), or maybe alternatively cut-and-paste whole tabs

Tab filtering

  • Unaries, but also extractors
  • Searches
    • by keyword or regexp-driven selection
    • locally, or through Twitter search
  • By natural language (or with translation?)
  • Flag arithmetic
  • Statistical summaries (changes tab type)

Tab merging

  • Binaries or more-than-binaries, also extractors
  • Usual set operations (union, intersection, difference)

Tab tools

  • Editors (when not external)
    • Tabular editor
    • XML editor
    • Python editor
  • Various features

Composition tab

  • URL and text shorteners
  • TwitPic and similar tools, for inclusions
  • Maybe spell checking, maybe translation

Strips (within tabs)

  • Logically holds a hidden composition tab
  • Maybe toggled as read, either in local tab or recursively
  • Strip editor

Remanent state

  • Generated locally
  • Sharable format (XML? Json?)
  • Synchronization

3   Accessory goals

  • Elegance, efficiency, and pleasure
    • Simplicity (a few dependencies, but not too many)
      • No framework (XUL, Eclipse, twisted, etc.)
  • Failure recovery
  • Synergy with
    • Web browsers (Firefox first)
      • twitter.com in particular
    • Email user agents (Thunderbird first)
    • local disk files
  • Scriptability
    • Both for chrome and engine
    • Triggers
      • Users
      • Local events (time, file changes)
      • External events (updates, notifications)
  • Subsuming other tools
    • Escaping lots of Web applications
      • Many do not do so much
      • Many want my credentials
    • Plugin structure
  • Maybe other protocols (likely later)

4   A plan, maybe?

  • Set up a team
    • Modus operandi (not fully cathedral, not fully bazaar)
    • Visual design, documentation, communication, development
    • Packaging and installation, distribution, maintenance
    • Per operating system and software architecture
  • Administrative setup
    • Project name, logo and motto
    • Web site, wiki, blog, mailing list (and of course, tweets!)
  • Produce a design
    • Concepts, terminlogy, architecture
    • Survey of various tools
    • Inventory of worth features
  • Artistic (chrome) preferences
    • Designers welcome!
    • GTK look to start with
    • SVG derived icons, Gnome aesthetic
  • Technological (engine) preferences
    • Python 2.5 or 2.6, pygtk, twyt maybe, git
    • Reasonable / minimal support for Gnome, KDE or other such
      • Yet Gnome and GTK drive the aesthetics
  • Development (chrome over engine, not instead of!)
  • Porting (Linux, then Windows and Mac)

5   Remarks

  • I really want to be a user, more than a developer or a lead
    • so little free time
    • too many things to learn (yet it would be fun!)
  • A collective experiment, then?
    • Niceties (brainstorm, synergy, speed)
    • Dangers (too soon, comitosis, bloat, riots)

6   Thoughts to develop

  • Architecture
    • Caching core
      • Twitter contact and API management
      • Local store (all knowledge stamped)
        • UserId to User
        • Stamp to UserId
        • User to MessageIds
    • Pluggable tabs GUI
      • Timeline tabs
        • Own, public, mentions, direct message, per user
      • Management tabs
        • own statuses
        • direct messages
        • favorites
        • blocks
    • Other pluggable script applications
  • Development platforms
    • Python
    • Erlang
      • erlang_twitter capabilities
      • Support for GTK / Glade? Pango? Cairo?
    • Air
  • Co-routine connexion queues
    • One input, multiple output
    • Multiple input
  • Databases
    • Sharability
    • Compare SQLite, MySQL, DB API, Mnesia