+1's: 1,746
Reshares: 175
Views: 284,796
Post URL
Wednesday, April 9, 2014
Monday, February 24, 2014
About Pixels - Display size, resolution, viewing distance and more...
about pixels
considerations on display size, resolution, viewing distance
DISCLAIMER: goo.gl links are no longer valid. Just click slide images to see presentation slides. Sorry.
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
considerations on display size, resolution, viewing distance
DISCLAIMER: goo.gl links are no longer valid. Just click slide images to see presentation slides. Sorry.
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):
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
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.
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)
(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: https://goo.gl/T9iwhL 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
Link to slide deck: http://goo.gl/y4Mx4G
Link to Java source code Main.java: https://goo.gl/T9iwhL 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:
Comments are welcome, either below or via email: 2to32minus1@gmail.com
Copyright © 2013-2014 Richard Creamer - All Rights Reserved
Subscribe to:
Posts (Atom)