N950 Arrival and My Development Plans

A couple of weeks ago I was notified by Quim Gil that I was selected for the MeeGo Community Developer Device Program for a Nokia N950 devkit.  Prior to this I had been quiet in Maemo-land for a little bit while I worked on an experimental rewrite of one of my applications that uses PyGame.  Seeing as PyGame isn't on the N950 I hurried up in getting it to a state I could put aside and moved on to learning QML.

The excitement increased as I saw the box personalized with my name regardless of that personalization just being a piece of tape

MeeGo Development

My development plans have changed (and frustration increased) over time as the MeeGo development story has gotten refined.  This is due to both changes in the UI toolkit availability and rules for distribution of applications.

Originally when things shifted to Qt I chose QWidget because it was ready now, includes widgets, and was recommended by Nokia (you know, the people who own Qt) for the types of apps I write (which recommendation was removed on June 22, 2011).  At MeeGo Conference I found out that some (most? all?) MeeGo instances are not including QWdget themes (which without a theme its basically dead).  QWidget in Qt5 will be optional and will probably not be included on those same MeeGo instances that currently don't ship a theme.  So there goes that work.

I am still a bit frustrated with QML in that there is not even a subset of common QML Components between platforms though some disagree on it being a problem.  I've just seen really terrible QML applications which mostly stem from everyone reinventing the same bugs when writing widgets from scratch.  I also find it a wonderful experience having the widgets available for the desktop such that I can write apps in a desktop environment that are targeted for small screens without the need for any pesky IDEs and emulation.  When it comes to testing, I am much more efficient testing and debugging natively on the desktop and just need to spot check how it translates to my devices.

I do not look forward to packaging for generic MeeGo.  I found out at MeeGo conference that dependency management isn't guaranteed to be included and one has to include in their package any dependencies outside of core MeeGo.  This is fine for compiled applications, you just pull in static libs.  This is not as simple for Python developers where part of the beauty is your program isn't compiled and any compiled extensions are distributed and maintained separately.  I have contemplated some tools to simplify this (based on cx-freeze and Hatchet) but that is a good amount of work and focused away from what makes all of this fun.

At MeeGo conference I raised my concern for packaging Python applications during the apps.meego.com lunch time BoF.  The impression I got then (no clue if things have changed) is that they will focus on MeeGo compliant apps at first and might later support others.  Even with that concession this is a stark contrast to the original vision that helped bring me on board from Maemo about (what was then called) Surrounds which would serve both as an app repo and as a place for third-party dependencies.  If I chose to not bundle all of my libraries then I also am not available for any of the other distribution channels (and any contests they might be running).  I don't program for the reward of the contests but it isn't fun feeling excluded.

The beauty of developing for Maemo was it had very low friction in the development story thanks to Python that I was able to spend more time focusing on what was fun: designing software for end-users to enjoy.  I feel that this is being lost in MeeGo.

MeeGo and Nokia

The picture can be better when focusing on a individual vendors.  Vendors may keep things a bit more lax with their distribution channels.  The problem is then you are customizing per vendor which requires device availability for testing and a lot more work.  That vendor has to be worth it.

Nokia is worth it (even without the DDP).  Nokia actually shipped a great device previously (N900 running Maemo5) and is committed to shipping the N9.  That is a lot more than other vendors can say.  On top of that Nokia offers a great experience with the software and hardware.  So as a user, Nokia is worth it.  What about as a developer?  Nokia has Qt Quick Components to provide reusable QML widgets.  They also will support dependencies and have Python/PySide available in their store.

The Way Forward

For my initial ports I will continue to focus on what keeps this fun, writing apps for end-users despite any downsides of being vendor specific.  After that I will bite the bullet of making my applications MeeGo compliant to make them available for a wider audience.

The default date.  It's good to see somebody at Nokia has a sense of humor

I have work to do on all of my applications but I will be focus on the ones that still use GTK first, especially since they are fairly simple.   I am using QuickNote as my playground for learning QML.  Expect further posts regarding progress updates and lessons learned regarding QML and MeeGo 1.2 Haramattan.

Google CR-48

Today I was asked my opinion on my CR-48 ChromeOS netbook to help with a purchasing decision for a Chromebook.  I thought I'd share my thoughts of having used it for the last 6 months.

I have a plethora of devices including most of the Maemo family (just missing the n800), some netbooks I got free through various (legal) means, and my desktop.

Whenever I am out and am needing something bigger than a handheld, I rarely choose something other than my CR-48.  This is because most of what I use are the various Google web apps and I can limp along on other use cases that don't fit in as well.  As an example, my CR-48 leaves the house once a week for my church meetings to assist me in my current responsibilities which is facilitating administrative matters so our congregational leaders get to focus more on assisting people.  An example of when I might chose another device is when I travel to various Maemo/MeeGo events where I'd want something that is a bit more prepared for python development.

The other main use of my CR-48 is what I'll refer to as opportunistic internet usage.  What I am referring to is the reduction in friction when having the thoughts "Oh, I'd like to look up ..." or "I should record ... so I don't forget" enough that you will act upon that thought more often.  This is when I am sitting about the apartment (or out and about) and my phone isn't quite enough to satisfy my need.  This is something harder to quantify when doing comparisons so it is usually not even thought of.  A tablet could also serve this purpose well except they are pricier and don't have a physical keyboard.

With any netbook you have to be honest with yourself about the reduced functionality due to their design, it is just more so the case for the CR-48 as you only have access to a web browser.  This can have some benefits though.  I remember an observation made to me back in the days of PalmOS.  My father preferred PalmOS because it wasn't imitating the desktop.  Why is that good?  When the imitation is too close you are more likely to get frustrated at the gaps when you come across them, sort of an uncanny valley of features.

So what devices should someone have?  It depends on your use case.  I've generally been a person who has preferred a cheap portable with the work horse being their desktop.  This has the benefit of being less paranoid about the portable device and making it easier to replace it when needed combined with the cost savings of a desktops (especially when you go 6 years without replacing them).  It is hard to say what I would get myself when left to my own devices (pun intended) since so many of my devices have been free.

ps If you are reading this and dream of robbing me, look further at the specs, release dates, and niche role of the various devices I listed.  It won't be worth it.

Google+

I still don't have too many people on Google+ but I thought I'd record my thoughts

Circles

I love them.  Some people are a bit confused about them and consider it a privacy risk that people can add you without your permission.  FB has the same problem but doesn't do a good job of telling you.  In FB if you send a friend request and it is never accepted/rejected then your feed will display any public updates from that person.  Google makes this explicit and emphasizes the benefit of it by having a "following" circle by default.  I think it is a much better and simpler model than "friending" products and people or "liking" their Page.

I'm still playing with what I want in circles.  Too granular of circles means you have a lot more to manage for each post.  Right now I am looking at "family", "friends", "acquaintances", "local", and "professional"


For cleaning up my circles over time, I'd appreciate a mass-edit mode where everyone is a row in a table and the columns are the circles they are in.  Bonus points for Google also showing who has not added me back and who I've not added back.

Posting

I like that when commenting on posts you can see what the visibility is of that thread.

Sometimes privacy on my posts isn't a big deal, like talking about programming for MeeGo.  It'd be nice if you could use your circles not just to restrict communication but say "these people will actually care but allow it to be discoverable for people I'm not connected to yet".

Another variant of that global-sharing-with-focused-audience use case is my use case for Twitter.  I originally joined twitter so I could track MeeGo Conference hashtag and know what else was going on around me while in attendance.  A Similar use case that a friend pointed out is tracking live news for things like the Texas legislative session.  I don't think I've seen a G+ equivalent system to hash tags but it will be hard for it to compete with Twitter without it.


Notifications

This is one of the killer features, being able to check on my notifications within GMail.

Feedback

It is nice that it is so easy to find how to provide feedback to Google on Google+.  It is also a really slick tool.  I've already sent them several items for improvement.  I hope they roll this out to their other services.

Integration with other Google products

Currently there is some integration with Buzz and Picasa Web though I am unsure of what Buzz's role is now and am thinking of disabling it.

I am looking forward to this being improved.  Good Google Calendar integration is a must for being a FB replacement.  Blogger shouldn't be too hard to also tie in.  I'd like them to solve the GMail / Google Reader integration issue but not too sure how they'll pull that off.

Contacts integration is actually where users will probably see the greatest troubles.  This is due to trying to bolt together different services that don't always have their data coordinated.  Users have unmerged GMail contacts, contacts creating G+ accounts with different email addresses than what are in my contact book, and the various tags I have from people.  It'll be a mess even with Google's help to try to match up all of these representations of people.

Back to Picasa Web.  I figured I should go back and update my tagging of people in my pictures.  Sadly I can't find the really helpful mass-tag tool that lets you look through all the faces it found and tag them.

Google Takeout

One of the reasons I am loyal to Google products (besides reducing the number of accounts I need) is the ability to leave and this is no different.

Final Thoughts

As I said, Google will need to improve their service integration and slowly ramp up their algorithms taking care of things for me.

Reaching critical mass will be a challenge.  Some might compare this with the migration from MySpace but this is even harder seeing as there are even more users with more history in the service to leave behind.  Maybe that is a good thing, to have a fresh start, but there are some connections that might not transition over that I would miss.

A question for me: where do I post things?  Facebook, Twitter, or G+?