Wednesday, April 9, 2014

Wow!  A recent Google+ posting's stats: 

+1's:           1,746
Reshares:   175
Views:        284,796 

Post URL


Monday, February 24, 2014

About Pixels - Display size, resolution, viewing distance and more...

about pixels
considerations on display size, resolution, viewing distance

I've been wanting to write down these thoughts for a long time and finally got the time:)

The presentation on this page (goo.gl/f6IlQF) describes a fundamental way of defining human vision's ability to resolve fine details in displayed images/graphics based upon the pixel subtended angle vs. dpi metric.  Oh, and more... ;-)

Slide titles:

- Human visual acuity
- Minimum point separation
- Computing pixel subtended angle
- Computing ideal screen size
- Ideal screen sizes for various resolutions and pixel angular size
- Comments

Here is a link to the presentation PDF: goo.gl/vylQin

Below are images of the presentation slides (click to enlarge):










Copyright © 2014 Richard Creamer - All Rights Reserved

Thursday, January 30, 2014

Google+ Now Offers Topic-Based Browsing

I see that Google+ recently announced topic-based browsing.  This is a good thing, but it only partially fixes half of the problem.

Google+ should allow posting authors to tag their posting with one or more topics.  Furthermore, topic posters should be able to publish a small topic tree of the topics to which they post.  Followers should then be allowed to view this tree and subscribe to different topics (channels) or branches.  This way, followers who want to see photo posts but not programming posts would only see photo posts.  The net result is that followers would have a higher density of interesting posts in their Home streams, and posters would not lose followers by posting content uninteresting to many of their followers.

With Google's NLP and Machine Learning talent, I would think that poster topic category trees could be computed from their historical posts, and that from View and +1 statistics, topics of interest to users/followers could also be computed (recommended to be precise).  So, having people explicitly stating their postings' topics and followers the topics in which they are interested may very well be unnecessary.

Below are some half-baked preliminary ideas I posted in 2011.  If topic trees and follower subscription to tree nodes were implemented, I'm not sure Circles would offer any benefits.  And, the diagram below would be much simpler if the center Circles tree was eliminated.



Copyright © 2011-2014 Richard Creamer - All Rights Reserved

Tuesday, January 28, 2014

Surprisingly High View Count on Photo Posting Spreadsheet

Okay, it has been about 36 hours since I posted the previous Google+ photo posting statistics spreadsheet so I thought I'd go and take a look at how many views the spreadsheet posting has received.

Well, it turns out it has been viewed 11,679  times!  This raises many interesting questions about the inner workings of Google+.  Here is a screenshot of a snapshot of the view statistics (click on the image for full 1:1 resolution):


By comparison, one of my more popular photo postings receives only about 1,000 views over longer periods.  Since a large fraction of my followers probably added me because of my landscape photography postings, this makes the spreadsheet views statistic quite surprising.  I wish I had access to the attributes of the people who viewed this posting, ideally broken down by company and photography fan vs. techie.

Monday, January 27, 2014

Google+ Photo Add Statistics

Google+ Photo Add Statistics

(This is just a quick, possibly to-be-continued posting...)

I added a photo to my profile and several Google+ Communities last night at 8:13 pm.  The attached image shows a screenshot of the associated statistics after a 12-hour overnight period.  I haven't yet decided how I want to visualize this information...  I'm certainly too busy to spend additional time on this exercise this week:)

(Click on photo to see 1:1 resolution)

Monday, January 13, 2014

A Method for More Intelligent Touch Event Processing - Most Likely Widget

A Method for More Intelligent Touch Event Processing

Link to slide deck: http://goo.gl/y4Mx4G

Link to Java source code Main.java: http://goo.gl/Mx6bBi   NOTE: Lines end with just \n not \r\n

The above PDF slide deck summarizes ideas for reducing the frequency of accidentally invoking unintended UI widgets on touch devices.

The Java unit test draws an overlay semi-transparent graphic which visualizes which widget is activated for each pixel in a mockup e-mail app.

Summary

• Desktop pointing devices (mice) have precise, single-pixel accuracy - touch devices do not


• Depending on device attributes, touch users are lucky to achieve an accuracy of 10-30+ pixels


• This causes many occurrences of: User intends to activate widget A but inadvertently activates nearby widget B


• The reason this problem exists is because touch device and OS OEMs assume that the legacy desktop single-pixel precision model will work well on touch devices - this is a poor assumption


• My recent experiment suggests that the frequency of inadvertent widget activations (event-to-unintended-widget mapping) can be improved


• The above URL slide deck summarizes a project I did over this past weekend to demonstrate that, for one simple UI at least, an algorithm for mapping touchevent (x,y) points to widgets which considers touchpoint-to-widget centroid distances as well as which widget's bounding rectangle contains the touchpoint (x,y) can provide the user with a parameterizable/tunable margin of error border around widgets which has the potential to substantially reduce the activation of unintended widgets


• I might add that inadvertently activating an unintended widget can be dangerous if the unintended widget were to, for example, open a malicious URL or e-mail


• More work is needed to evaluate and refine the proposed method in a variety of UI contexts, but I believe the presented algorithm has merit


So, extremely weary of using touch device UIs which frequently activate the wrong widget, I spent some time this weekend developing and validating (on one simple UI) the above simple algorithm which offers imho a better approach to map touch event (x,y) coordinates to UI widgets.

Below is a screenshot from this mini project I did over the weekend showing a semi-transparent overlay encoding, via color, to which widget a touch event at each pixel would be mapped were the current naive Widget.rect.contains( Point pt ) logic to be replaced with a simple algorithm based on touch point distance to widget centroids + which widget's bounding rectangle contains the touch point (x,y).

Original Google+ post on this topic

Below is a screenshot from the unit test touch-widget event mapping code:




As can be seen in the above screenshot, touch points anywhere within the semi-transparent red circle for the top checkbox would be routed to that checkbox.  This provides users with a margin of error which should reduce the frequency of having the wrong/unintended widget receive the touch event.  Note that the left and right overlays pertain to two different centroids for the checkboxes: Left: centroid is for checkbox alone, Right: centroid is for table cell which contains the checkbox widget.

Comments are welcome, either below or via email: 2to32minus1@gmail.com



Copyright © 2013-2014 Richard Creamer - All Rights Reserved

Tuesday, July 23, 2013

Idea for using Google Glass for Autism Research Study




Thought I 'd just mention a quick idea...

I got an idea yesterday which may be a useful application of Google Glass.

In a nutshell, my idea is to have a research group/population of young parents wear Google Glass when interacting with their very young children.

The camera and microphone in the glasses, in conjunction with specialized software, could statistically characterize and analyze/track infant eye movement and sound/voice/speech patterns over time.

Should a rapid degradation in, say, the degree of infant eye contact, be detected over a 24-48 hour period, a notification would promptly be generated to the parents and researchers along with supportive data.

In such a situation, the parents' memory of what specific factors the child was exposed to in the past days/week would be quite complete and accurate while the resulting suspect causal factors would be narrowed down exponentially thus giving researchers a much shorter list of possible Autism causal factors to contemplate.

The above assumes that children can sometimes transition from normal to ASD over a very short period (days). Many parents have stated they feel this is the case, however, this may not be the case.

Here is the URL to the Google+ posting I made earlier today where I describe the idea in more detail:



https://plus.google.com/109632926185753183937/posts/EJZvHvyh13h










That's a wrap...