Menu

#1 web designer/developer features

open
None
5
2008-03-02
2008-02-27
No

For web designers/developers the two most important types of information are the users' browser display window resolution (the area available to content and the dpi) and the types/generations of user agents.

It is hard to promote fluid/flexible/resolution-independant designs to customers, if you can't show them a statistic of how diverse the displays are. This can be realised by including a little bit of JavaScript in the home page or CMS template. See http://evolt.org/article/ds/17/2295/ for an old, but thought-through example using cookies. Another way to do it is described here: http://www.loganalyzer.net/log-analysis/screen-resolution-analysis.html

And in the end every developer has to make a choice of which standards/features to use and which clients to test with. This would be much easier if there were statistics available showing which browser generations are used with a site. I don't need to know every bloody user agent string there is, but I want to know how many users are using IE, Mozilla, Webkit or Opera and the major version numbers. So a statistic of user agent groups is needed. Even better would be to query the browsers' capabilities and build a statistic of that.

Some kind of warning sytem (like the one you are proposing on your website to warn you if have for example been slashdotted) would be nice, so that the statistics package can warn the webmaster if there are suddenly lots of user agents that can't display the site properly (for example a cool new product like the iPhone or a new STB might be released and it can't handle your site).

Discussion

  • Dustin Spicuzza

    Dustin Spicuzza - 2008-02-27

    Logged In: YES
    user_id=915641
    Originator: NO

    The first item is hard to do, only because of the way OWS is designed: analyze log files, as opposed to adding to the database on the fly. Though, it could be implemented like so: js opens some page and sets the GET parameters to the particular items (ie, stats.html?resX=1024&resY=768&etc.. ), and then some plugin looks for accesses to that page and creates stats from it.

    The second one almsot got implemented, but then I just didn't have time... I was actually going to use the browsecap library (its in SVN too, just isn't used for anything yet: http://obsessive.svn.sourceforge.net/viewvc/obsessive/trunk/plugins/include/ ) to do a better analysis on agent strings, because as you pointed out, the current system sucks. It would be trivial to add however.. maybe I'll do that this weekend or something.

    The third one would be nice, I agree.

     
  • Dustin Spicuzza

    Dustin Spicuzza - 2008-03-02
    • assigned_to: nobody --> randomperson83
     
  • Dustin Spicuzza

    Dustin Spicuzza - 2008-03-02

    Logged In: YES
    user_id=915641
    Originator: NO

    Heh... I missed the link you posted, which described the same thing I mentioned. Anyways.. at first glance, Item #1 seems like it would be really trivial to implement -- and it is, except that there needs to be *some* way of associating the browser with the original page access, and at the moment OWS doesn't have any notion of 'visits', just page accesses. So, implementing it at the moment would actually be non-trivial (which surprised me), so I'm not going to mess with it...

    However, I have added better agent analysis using the browscap library to the version of OWS in SVN, its implemented as a separate plugin ( 09_ows_agents.php ) which extends the agent dimension. On the demo site (obsessive.virtualroadside.com), you can see the fields it adds using either the manual analysis tool, or by enabling the excessively obsessive options, and filtering using the 'where' clause. Check it out, let me know what you think.

    Of course, its annoying to use at the moment given that none of the built-in queries support it yet.. after I add support for it there, then I'll make a release with this in it. Haven't decided the best way to integrate it however, seeing as it is a separate plugin. I've been meaning to make the primary plugins more extensible anyways..

    At this time, I'm not going to implement item #3 either.

     
  • Nobody/Anonymous

    Logged In: NO

    Cool, its great to see improvements happening so quickly. :-)

    For the moment I'm rather busy (exams coming up), but as soon as I get some time, I'll give it a try.

    Thanks!

     

Log in to post a comment.

MongoDB Logo MongoDB