Yesterday I helped my pal Peli deHalleux at the AppDay event in South Seattle, hosted at Rainier Beach High School. The gym was packed with 400 students from local high schools and a couple of middle schools. Each school was challenged to complete programming exercises with TouchDevelop on a smartphone, tablet or laptop.

It was cool to see the students embrace the challenge, help each other get unblocked and finish the exercises. Some of the students went beyond the exercise plans to create novel apps with a programming language they had no prior experience with. I heard several girls at the event say: “I’ve never coded before…” yet they finished the exercises then invented their own apps.

 

 

 

 

 

 

We need more girls interested and thriving in computer science. But we also should encourage students who don’t normally seek CS programs to at least experiment and apply their creativity.

Prior to the AppDay event I prepared a sample app which consumes a feed from the research.microsoft.com odata service.

 

 

 

 

 

The sample app came in handy to show the students who didn’t have devices at the event or were finished with their exercises.  And they can use the feeds from the odata service anytime to continue building apps with TouchDevelop.

Yesterday I attended MobileUXCamp in Seattle; at the University of Washington, Mary Gates Hall.  It was another good turnout of UX pros mashing up thoughts about where mobile is right now and where it might bes going.

Some in-the-moment notes from the event below:

See ya next year campers.

We recently updated the Microsoft Research OData service found at http://odata.research.microsoft.com.  The service now supports JSON output.  Here’s the root endpoint:

http://odata.research.microsoft.com/odata.svc/

 

Give it a try, build some apps.

 

 

As I’ve shared before, my team manages the web space for Microsoft Research.  This includes the web platform at http://research.microsoft.com.  Like any web team we take a keen interest in web analytics.  Earlier this year we decided to experiment with visualizing web analytics in an HTML5 canvas app; which ended up as two separate apps we built for different display scenarios.

For large displays:

http://research.microsoft.com/en-us/um/redmond/projects/sawmillatrium/largedisplay.htm

For tablet displays:

http://research.microsoft.com/en-us/um/redmond/projects/sawmillatrium/tabletdisplay.htm

 

Each app visualizes the top people, downloads, publications and videos according to http://research.microsoft.com pageviews for these assets.  The left side of the app focuses on the past six months time period while the right side of the app [the info card if you will] focuses on yesterday.  The cool thing about the app architecture is the data is all RSS feeds generated by the web platform; which means these feeds could be consumed in other apps.

Visualizing data is a nice way to engage audiences but it also gives a view into traffic patterns on the site we might not normally see with traditional web analytics tools.

Perhaps the next evolution of smart web design is morelets. Let me explain.

Responsive design does a nice job of making web sites easier to read content on whatever device you happen to be using; adapting to the viewport [screen] in an elegant, dynamic way. But responsive design doesn’t help you focus on what you’re likely to read to the end. This is where we could use some help from a new mechanism I’m calling the morelet. The morelet acts like a recommendation system.  It presents content that you’re likely to invest time to read completely, i.e. all the way to the end. The rest of a web site’s content is still there and rendered nicely in responsive design but deemphasized in favor of morelets.

But how does a website know what morelets to create for me?  There’s some machine learning that would be required to train the morelet system about your reading patterns based on sites you’ve visited.  These patterns could then be applied to any new site you visit that has similar content, to present morelets.

More on morelets later…

is not the same as making web content beautiful.

Been thinking and reading a lot about this. This is in large part driven by the reality that sometimes we [people browsing, checking out web sites] have almost no control over the content we browse; yet we have an expectation of a web site – all web sites – being beautiful and compelling.

Can’t immediately recall if I posted about this previously but it seems there’s a trend with web content quality going on.  There’s all these great frameworks for building web sites - think JQuery, responsive design and HTML5 templates – and equally there are great tools for creating media – think cameras that get better each day, still and video; and PhotoShop plugins, video encoders - and yet many web sites are just plain, or plain ugly. Is this because web site owners don’t care about the beauty of their sites? Or perhaps they don’t receive negative feedback from site visitors. Or perhaps their site’s purpose has nothing to do with being beautiful.

I ran a quick test with FlipBoard to see what it would produce from some of our more visual content; the rendered output is impressive:

Based on this simple experiment, I wonder if web site owners are depending on FlipBoard-like apps and iPad-like devices to make their sites appear to be beautiful.

Wouldn’t it be cool if the search engines had a beauty filter; some query parameter to return only beautiful web sites? The problem is [as we all know] beauty can’t be defined.  It’s in the eyes of the web browser.

Deborah and I were driving to campus today; we noticed someone texting which started us talking about the driving-while-texting problem. From my POV texting isn’t the problem, it’s a symptom. So what’s the problem then?

Lets start by remembering PDAs. Bill Gates had a vision of the ‘personal web’ circa Comdex 1999 that’s very similar to how Personal Digital Assistants evolved:

http://www.microsoft.com/misc/features/comdex99_billg.htm

The modern PDA [smartphone] should know that you’re driving a car and thus would not let you text message [or anything else that distracted you from driving]. The PDA should also know when you are at home, trying to have family time, say having dinner or helping your child with homework. Thus the PDA would prevent you from checking email or doing something other than being present with your family.

Today we don’t have the discipline to unplug, stop looking at a screen. We need something to help us remember what’s really important, in the moment.  Let’s assume the modern version of the PDA is a smartphone; then let’s further assume the smartphone – with all the capabilities for contextual awareness – should be able to help us get focused on what’s important at the moment, or to not let us use the smartphone when the moment is inappropriate.
There was a great article written during/about social networking at Burning Man that ties into the importance of being present with what’s around you:

http://www.readwriteweb.com/archives/the-social-network-is-all-around-you-a-lesson-from-burning-man.php

What caught me about the article was how odd it seemed to be at an event like Burning Man and not be present to what’s around you.  It’s almost a walking-while-texting scenario on a grand scale in that Burning Man is a timed event: it starts, gets built up, reaches the apex, then it all goes away.  Why waste any time messing with a smartphone when you need to be experiencing the event?

A smartphone should be that little assistant - YOUR assistant serving YOUR needs – that checks in once in a while; helps you make smart [why is it called a smartphone?] decisions.  It shouldn’t distract you.

 

David Pogue wrote a related app distractions post on his blog:
http://pogue.blogs.nytimes.com/2012/10/04/do-we-ban-app-distractions-too/?ref=personaltechemail&nl=technology&emc=edit_ct_20121004