ilya's profileBetween the EarsPhotosBlogNetwork Tools Help
    September 28

    I need a Blog++

    I have a problem. It's not a big one, and i think it's only a problem because i think it's a problem, but here's the rub: i find lots of very interesting stuff to learn about every day. I also have very little time to follow up on all that interesting stuff, to research it, internalize it, so i can ultimately make use of it some day in some fashion.

    I want to make a record of that stuff, lightly categorize it, and make absolutely sure that i can later find it easily, without spending tons of time searching for what i need.

    So, shat do i do with all that stuff? where do i file it? how do i store it so that it's easy to find, ubiquitously available (online and offline), and a snap to add to and expand?

    The two candidates that came out on top for addressing my problem are compared below. The other possible solutions i considered were Excel-type workbooks, and simple web-based lists (similar to what's available here on Live Spaces). The former is too tied to a physical location, although something like Live Mesh could fix that to some extent, and the latter are, essentially, a different incarnation of a blog (which is just a list anyway), so don't warrant their own comparison.

    Paper notebook

    Advantages

    • old fashioned :)
    • easily accessible
    • readily available

    Disadvantages

    • you have to have the notebook on you to make notes, which means carrying something else in addition to my phone (which is the maximum i'll carry nowadays, excluding my wallet). 
    • it'll become unmanageable as it grows
    • it's hard to write down URLs
    • can't really expand easily without making the whole thing messy
    • Sharing those notes is problematic, too.

    Conclusion

    Paper notebook, while may be an interim solution, isn't the final solution to my problem, at least not for me.

    Blog

    Advantages

    • easily accessible
    • readily available
    • easy to add to
    • easy to share
    • searchable

    Disadvantages

    • Requires an online connection, so it's only as ubiquitous as your phone's mobile web access
    • Not very suitable for capturing info about physical media (newspaper articles, for example)

    Conclusion

    • Way better than the paper notebook, but a couple of disadvantages make it less than ideal. After taking these notes, i'm thinking a software package that addresses the two disadvantages (offline caching, and some kind of a physical world-to-internet world interface might make this exactly what i'm looking for.

    How could the blog disadvantages be addressed? The first one, online connectivity, would clearly require something like Google Gears or a local data caching application and sync for online/offline entry of data and search. I'm not a Gears person, so i'd probably opt for a .NET data caching app for my Windows Mobile 6 device.

    The second one - bridging the physical-to-virtual gap - may be more difficult. One idea i had was using the phone camera for snapshots of physical objects, and integrating that into the data caching app for Windows Mobile for metadata/attribute collection. This would work, although it wouldn't be as effortless as my next couple of thoughts. One would be to embed a unique code (barcode, or a dataglyph) into each printed article (for example); this code would then be captured with a phone camera, and as part of my blog-caching app, be then sent to a central processing service for look-up. The result of the look-up (providing there's a match), would be then sent to my blog as an entry, indexed, and available for keyword search and retrieval. The data glyph approach is too fragile and will never be universal, so there's a flaw in that design :).

    An alternative to the ID glyph may be "fuzzier" in terms of results for the blog, but wouldn't require any change on the newspapers' printing process (this would make it much easier to actually implement in the real world, and wouldn't necessarily depend on the newspaper's willingness to adhere to the process). In this alternative, a photo of the article's first paragraph (for example) would be sent to the central service for OCR, and the text would then be used in a web search query. Some magic would have to happen after that, making sure the right result was sent back to my blog (probably in draft mode, pending my final review and approval). This also might actually be a "feature" rather than a detraction: it's a good way to add possibly related material to my initial article of interest, which is a good thing, considering that the point of the exercise is to expand my boundaries, and so including content i might not have stumbled upon on my own is very much relevant to that goal.

    So... sounds like a Blog++ is the answer to my problem. Now i just need to figure out if someone has already built it, and if not, how i'll go about building it myself :).