We can definitely extend our desktop detection to do OS detection too. So the reason that we have desktop detection is for backend responsive/adaptive web design. Desktop users have a mouse and a much larger viewing area. Phone users have a touch screen and a much smaller viewing area. That is an extremely important distinction to be made when you are serving a responsive/adaptive layout. So I would be careful when you say that desktopDevice is quite meaningless :)
Sure, there are other use cases for DeviceMap where you want to know more specific information about a desktop. So maybe we should step back and better understand who are our potential users and how they plan on using DeviceMap? Are they doing responsive/adaptive web design? Web analytics? Something else? Just an FYI, I spend a *lot* of time working with frontends, responsive, and adaptive designs, so my opinion is always heavily steered towards this use case. ________________________________ From: Werner Keil <[email protected]> To: "[email protected]" <[email protected]> Sent: Tuesday, July 29, 2014 8:59 PM Subject: Re: Take stock Based on initial OpenDDR (desktopDevice is not new btw. only got a few extra properties or screen "assumption" changed from 800x600 to 1600x900, whether that makes sense is another question) experience told us, that e.g. Apple devices of all kind, including MacBook, etc. had a more descriptive recognition based on "genericApple". Hence it is dangerous and leads to missing even the most trivial information like the "Windows" string for the OS if the fallback is too generic. There is a "genericLG" which could under certain circumstances act as the most common fallback for an LG phone with Firefox OS, but now there is a generic OS root, too. W3C DDR and implementations like Open/DeviceMap DDR know at least 3 "aspects", if you want those are extensible, so having a fallback "hardware" or "OS" may conflict with each other, see the "desktop" which is quite meaningless and loses the information that this is a "Windows" desktop at the moment Werner On Wed, Jul 30, 2014 at 2:43 AM, Werner Keil <[email protected]> wrote: Well there are 2 aspects, one API, the "new/alternate" client may evolve, and putting those things in JIRA is not wrong. >Whether the person responsible for a component (i.E. Reza for the Java client >or yourself for .NET) just picks something or there is some sort of "voting >process" (with a series of +1 or similar, see Eclipse, I also recall having >heard about that somewhere here) that is probably worth considering. > > >Even though design patterns are applied in most modern languages, not >everything might be applied exactly the same way on the .NET side, so if you >don't see the need of a "factory" for something there, just leave it. > > >The data can use some care, not just for brand new platforms, and IMHO adding >a reliable recognition of new families like Firefox OS, Blackberry 10 or >Windows Phone 7 or 8, the certain age of the baseline means there's a lot to >do and no need to wait. We may rarely have JIRA tickets other than from actual >committers now, but even on GitHub there are one or two ODDR either overlooked >or did not consider a high priority including a fix for BlackBerry OS which we >are probbly still missing in the current device-data. > > >I'm afraid, the "desktopDevice" doesn't add that much value right now, given I >see: >model: browser >ajax_support_getelementbyid: true >marketing_name: - >displayWidth: 1600 >id: desktopDevice >device_os: - >xhtml_format_as_attribute: false >is_crawler: false >dual_orientation: false >nokia_series: 0 >device_os_version: - >nokia_edition: 0 >vendor: desktop >mobile_browser_version: - >ajax_support_events: true >is_desktop: true >ajax_support_inner_html: true >image_inlining: false >mobile_browser: - >ajax_support_event_listener: true >ajax_manipulate_css: true >displayHeight: 900 >is_tablet: false >inputDevices: - >ajax_support_javascript: true >is_wireless_device: false >ajax_manipulate_dom: true >xhtml_format_as_css_property: false > > >running the console demo or any comparable Java client app against a local >Windows 7. >So "is_crawler" or even a new "pixel_density" which might be of relevance to >Retina screens, could be a nice extra gimick but a default display of 1600x900 >is meaningless for a desktop and http://www.useragentstring.com/index.php >tells me this > > >Chrome 36.0.1985.125 >Mozilla MozillaProductSlice. Claims to be a Mozilla based user agent, which is >only true for Gecko browsers like Firefox and Netscape. For all other user >agents it means 'Mozilla-compatible'. In modern browsers, this is only used >for historical reasons. It has no real meaning anymore >5.0 Mozilla version >Windows NT 6.1 Operating System: > Windows 7 >WOW64 (Windows-On-Windows 64-bit) A 32-bit application is running on a 64-bit >processor >AppleWebKit The Web Kit provides a set of core classes to display web content >in windows >537.36 Web Kit build >KHTML Open Source HTML layout engine developed by the KDE project >like Gecko like Gecko... >Chrome Name : >Chrome >36.0.1985.125 Chrome version >Safari Based on Safari >537.36 > > >based on the same UA: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 >(KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36 > > >So we are far from that I'm afraid, >Whether it's the hierarchy, that is rather likely something not only to be >fixed or introduced for Firefox OS. > > >I added an initial "genericFirefoxOS", feel free to experiment with extensions >to that. As of now I didn't add a child device that would detect say: >Mozilla/5.0 (Mobile; rv:14.0) Gecko/14.0 Firefox/14.0 > > > >Werner > > >On Wed, Jul 30, 2014 at 1:59 AM, eberhard speer jr. <[email protected]> wrote: > >-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>Hey guys, >> >>can you please "hold your horses" for a minute ? >> >>I think we all agree a review of the Vocabulary is in order -- for >>example -- but 'quickly' adding "is_somethingOrOther" to a 'patch' >>file and mentioning it in JIRA does not strike me as proper. >> >>And I think the same goes for 'quickly' turning this, that and the >>other into a "Factory" and adding a 'this' and a 'that' left, right >>and center to the API. >> >>It seems to me that after the recent votes, we should take stock of >>the situation, agree on what's next and *then* do the next thing. >> >>esjr >>-----BEGIN PGP SIGNATURE----- >>Version: GnuPG v2.0.22 (MingW32) >>Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >>iQEcBAEBAgAGBQJT2DV8AAoJEOxywXcFLKYcYwsH/RdIh7MmDONA9J0/CeSpES+B >>iEcK235gz+YkJtV7pmm/XhMsRs4CDAYBIqpCNik7DR7Im1PAdgElSEliXc/4uQoQ >>vWIBXqpb/KyVab8Q74GX9obHezAIOBGZW/+ZCWcmuNceCSLYBiA5DT5Ym0nyC6+Q >>4cRL1iQtfdewaAWblijEQG80QV0bfBBVhycHR0FZB1a8i+IXyQTcltP9LnngGy4L >>+wk8FkbdvnE9LftezvpZQz4Z9dxf+8n1Q7+T1zS9s82Q93EmrpClVveEbv6/emBN >>byayrXInTksgDiLRTx5ZFYq5W4AofxBTfue0/9MJ24uQKzoa5TKqjM2BpVePCZA= >>=Fsfe >>-----END PGP SIGNATURE----- >> >
