I think the Windows Phone team deserve some credit for doing this, knowing that the developer reaction to it will be deeply negative (read: most comments in this thread).
The simple fact is that it works better for Windows Phone users. If developers hadn't been using webkit-prefixed CSS everywhere it wouldn't be an issue, but it is.
That said, I wish Windows Phone IE had better developer tools. Both Android and iOS let you plug your phone in via USB and access the web console. It's great.
I agree. The first release of IE had a user-agent starting with Mozilla and its something all major browsers (Chrome, Safari, IE, Firefox) still prefix their user-agents with.
Mozilla/1.22 (compatible; MSIE 2.0; Windows 3.1)
Still none of that detracts from how broken relying on user-agent to improve user experience is.
Browsers like Chrome seem to handle features like webp support better with the Accept: image/webp header but even that has its limitations if you care about animated webp or not say.
This is also symptomatic of the way Windows clients have fallen out of favour with many devs generally. Android people have enough trouble persuading them (and designers) that the world isn't just Apple, but having a toolchain that requires Windows desktop? Instant not-going-to-happen.
Yes. It feels philosophically unfair to complain about, but I want a Windows Phone emulator for OS X. Of course, Windows users don't get an emulator for iOS either, but Apple has popularity on their side.
Couldn't you technically run Windows 7/8 under VMWare and then run the Windows Phone tools under that? VMWare has nested virtualisation (at least on Workstation 10 on Windows, think its there on Fusion or the Paralles options). And given MS give free VMs for testing IE on Macs too, your a step closer...
Last time I tried, no. This is going from memory so I may be incorrect, but the WP emulator required some level of hardware virtualisation that VirtualBox (at least) could not offer in that nested way.
Parallels supports this nested virtualization. The WP 8.1 emulator requires HyperV which Parallels supports. I've managed to get this working on a Mac with a Parallels VM running Windows 8.1 running a Windows Phone 8.1 VM. It... worked, but needed lots of memory.
The mobile web is just a disaster all around. I remember when I got my iPhone in '08, the browsing experience was amazing. Most sites were still relatively simple, and whatever highly non-standard tricks Safari played to do things like text reflow worked great on that small 3.5" screen. Half a decade later, I'm profusely disappointed with Chrome's browsing experience on my Nexus 5's massive 5" screen. Even on HN, I can't read the titles on the main page without scrolling sideways at any zoom factor where I can still make out the text. Reddit is better than most, but it still renders the "233 Comments" link text in miniscule text that's impossible to hit without zooming in. Advanced web technologies and CSS layout has turned the mobile web into a sea of too-small text, too-wide columns, pop-overs that are too easy to fat-finger, etc. /rant
I'd recommend ihackernews.com for browsing HN on mobile (not my website). I use it daily, and it's much better than the completely non-responsive HN site.
I'd like to join you on this mobile rant for a bit. Mobile browsing completely sucks right now. Whether it's websites that don't know how (or don't bother) to design with mobile in mind, or websites that do try to design with mobile in mind, and go completely over the top to the point that it ruins UX (Why do we still see websites where you can swipe left/right to switch articles. Does anyone every actually need to swipe through blog posts that rapidly?) It feels like there are very few websites that don't outright ruin mobile browsing.
And even when you find one of the nice ones, your browser mucks it all up by thinking it is smarter than the web designers. "Font Boosting" makes Reddit and several forums I frequent completely unreadable for me. Even on the mobile versions of the sites! It seems to get worse as you go down the page, and after 30-40 comments, the font sizes might as well have been chosen completely at random.
The other day, my phone warned me of low internal storage, and I saw the Chrome app was taking up 225mb of space on my android, and this is not including the additional 100mb+ from cache and data. That's 10% of my internal storage! Could you imagine if Chrome for desktop took up 100GB? /endrant
When I first experienced browsing with mobile devices the stand out feature was zoom. Double-tap on a column of text and it would zoom to fill the width of the screen. This (and similar navigation features such as swipe to scroll) made mobile browsing preferable to desktop browsing for me, despite the smaller screen. Fast forward a few years. Almost every website has a mobile version. Three quarters of these mobile sites (it seems) disable the devices native zoom. This makes zero sense. The device with the three inch screen is the one that needs zoom. It’s like the authors of mobile libraries are all twelve years old, can hear mosquito ringtones, and read microscopic text while bouncing up and down in the back of a car. Well, here is some news. People over thirty can’t read your website. The first thing we do when we get to your site is scroll to the bottom for the link that says desktop version.
Mostly its the fault of us web developers. We started building mobile-optimized sites, and that messed everything up. Now every mobile-"friendly" site has bloated retina graphics and uses very specific and carefully developed layout mechanisms that abandon zooming, fluid layouts and graceful degradation, because, you know, it's mobile, so that stuff doesn't make sense there. If we'd all just done nothing, the mobile web would be in a lot better state than it is.
(My personal pet peeve is onswipe, the most horrible mobile experience ever imagined, always worse than the desktop site on the same device, and yet ubiquitous.)
Mozilla, Opera and Microsoft have been complaining about this and Opera had already implemented support for the webkit prefixes(before switching to webkit/Blink entirely) and Firefox-OS will probably follow.
I disagree that the webkit tags are creating the new IE 6, after all (IIRC) they're prefixed because the standards behind them aren't yet finished.
On the one side I want to make a ramble about why it takes so long for those standards to finish and unprefixed CSS3 and beyond is possible, but on the other hand - without actual real-life use, how can you find all the edge-cases and practical application to create a complete standard?
Many of these properties no longer require the prefix for most browsers. For these properties having the webkit prefix only, without the non-prefix property to cascade to, is a problem. I recall many demos, examples, and live sites not displaying as expected in Firefox because the developer decided to use only the webkit prefix. If the webkit team were to start removing the webkit prefixed properties then those sites would have even more broken views.
They're initially prefixed because the standard is not finished.
Many of them are _still_ prefixed because WebKit has a policy of never removing prefixed features, even if they implement the unprefixed one. So people feel no compunction about using the prefixed stuff in production, and since they only test in WebKit they don't notice when they're using the -webkit-prefixed version even though every single browser (or every browser except WebKit, in some cases) supports the unprefixed standard version.
Yes. This is down to lazy, short-sighted developers, and it makes me insanely irritated.
It's ridiculously easy to make sure you include all appropriate browser-specific and generic prefixes for almost all experimental CSS features. If you use something like Compass, it's even done for you, totally transparently.
Lazy developers ruin it for everybody, again. What a surprise.
> I'm not entirely sure this is an accurate analogy. vendor prefixes solved a need.
No. It tried to solve two different needs: proprietary stable APIs and unstable/in-flux specs. And the abuse of the latter forced browsers to drop the use-case entirely and hide features behind flags because developers could not be trusted to act responsibly, so it definitely didn't solve that problem.
> Why should we be developing to the lowest common denominator?
That's not developing to the LCD, that developers deploying half-specified and unstable APIs in production.
Why do you blame developers? The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature) and for MS for developing a browser at a glacial pace.
Because the fault lies with them and no one else, no matter how in denial you are.
> The fault lies with the standards community for not standardizing much faster (at most a week after the second browser has support for that feature)
That doesn't even make sense, standards work is not "you shipped some random unspecified and mostly broken pile of shit and some other bloke was convinced to half-implement something which kinda looks similar if you squint so let's just call it standandard :shipit:"
The problem isn't that developers should be developing for the lowest common denominator. It is that the prefixes are not being dropped by websites even after other browsers start implementing the feature, or it's that they continue to use the webkit prefix for new websites.
It seems to me that vendor prefixes worked as intended. It allowed the HTML specs to be changed (for the unprefixed versions).
True, browsers need to support some pre-standardization variants for now, but this will fade. It doesn't seem like a huge burden for browsers to support older websites for a while, and it doesn't affect new websites.
I disagree. If the tags had been standalized then we would be using them. Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough.
> Unfortunately the standards commity dropped the ball on this one because they are unable to act fast enough.
These are features which changed semantics and syntax multiple times over the course of their standardisation, it's not like standards guys were slow because they found it fun
> If the tags had been standalized then we would be using them.
That query means developers by and large don't care and just cargo-cult through.
> The prefixed one is there for backwards compatibility.
Backwards compatibility with what, fucking Chrome 6? How many of these sites have been tested for backwards compatibility in Chrome 6? I'd bet it's somewhere around "none whatsoever".
Smudge raises a valid point. The presence of both the webkit prefixed version and the standardised non-prefix version is adequate. The problem IE Mobile are working around are those developers who have the webkit prefixes CSS properties, but not the standard no-prefix version.
Chrome won't remove them because it breaks these sites relying on the webkit prefix remaining - so there's sufficient ground there to indicate developers are failing. But it's not the developers who include the non-prefixed standardised version.
Yes, there are lots of developers who don't care - the ones who rely on the webkit-prefix support remaining. That is contrary to the spirit of vendor prefixes - experimental CSS properties that should not be relied on.
Those using both the webkit prefixed and the standard non-prefixed versions are using the typical graceful fallback - one that doesn't make other browsers "unsupported"
Preprocessors often have prefix support baked in. It's not about explicitly testing your site for backwards compatibility. It's about casting that net as far as possible with minimal effort.
And while IE and Firefox have supported unprefixed CSS transforms for a while now, Chrome and Safari only support the -webkit-prefixed version of CSS transforms so far. So if you want to do transforms, you have to use -webkit prefixes...
> Looks like the webkit prefix tags are creating the new IE6.
This bothers me. Webkit isn't some ancient browser that is has remained stagnant for years until google/apple decided to do something about it. Nobody spends hours debugging their perfect layouts in webkit. Webkit isn't holding the entire web back. It's just a poor comparison.
I browse mobile web in mostly firefox mobile, and I don't think I've ever seen a mobile site broken on FF but working on Chrome.
In fact at least Google has taken some steps to recitfy it, and they've stated they're putting experimental CSS properties behind developer flags. If we're talking about the fact that old people don't update old browsers then Microsoft is one to talk with IE7, IE8, IE9, and IE10.
Most of my professional time these days is spent on mobile/tablet websites for a major automobile manufacturer. And there are days when we absolutely do obsess over layout and other issues introduced by mobile safari itself. On the release of iOS 7, we actually probably burned a month working with a bug that we never found a solution to (which, fortunately, was fixed with iOS 7.1).
That last part underscores that we're fortunate browser makers are issuing regular updates (a big difference from IE). On the other hand, with some of those updates come new bugs and (particularly on Android) fragmentation. Consider that by 2006 there were enough people/resources documenting IE6's quirks that it was pretty rare to run across a bug that someone didn't have a good idea of how to fix/workaround. In 2014 when you run across a mobile bug (particularly one from a recent release, of which there are many), it may well be that nobody knows how to solve your problem, and in some cases nobody seems to even know how to tell you to duplicate it across devices/emulators (http://stackoverflow.com/questions/23142762/how-to-identify-... ).
And of course, like IE, many developers code webkit-only, even iOS only (and I know why: at the level of ambition people often have for mobile websites and with the difficulty involved in testing more than a few devices, it can sometimes seem like the only way to get things out the door).
IE6 was no picnic, but there are times I think to myself I'd rather be working on the 2006 desktop web than the 2014 mobile web....
I think you forget how bad it was with 2006 desktop. So many CSS hacks. We take our div layouts for granted but if you dared venture away from the standard table layouts of the early 2000s you were in for a lot of debugging for browser quirks.
Nowadays at least I code responsive layouts to target screen resolution, and its gotten leagues better. Sure there's a few quirks in separate browsers and things aren't necessarily ideal, but it sure beats the days of "I wish I could use xxxx CSS property but I can't because only 2% of my users would be able to render it".
The comparison is apt, just not entirely. It isn't a comparison of IE6 vs Webkit, it's of developer reactions to them.
For a long time, IE6 ruled the roost, so developers used IE6 as their development target. Browsers that moved beyond it, or implemented things differently (often correctly) were ignored.
On mobile, webkit rules the roost. Developers use it as their development target. Browsers that move beyond it or implement things differently (by using non-webkit prefixed CSS) are ignored.
I mentioned in another comment that when I think of IE6, I think of the hours spent fiddling with the HTML/CSS that works in FF/Chrome but not in IE6 because of browser bugs that were never fixed and standards not followed. It's why I think it's a bad comparison.
I guess it's a matter of perspective. My experience with IE6 was mostly being a teenage hobbyist webmaster way back when FF vs IE6 was in full spin - I remember being proud of coding standards compliant websites that worked perfectly in FF just to have it completely break in IE6, then having to spend hours fiddling with the HTML/CSS to get it to the point where it worked in IE6. Frustrating times.
That's why I don't really see the comparison. When I think of IE6 I think of the hours I wasted trying to make it work right. I'm not currently coding IE mobile websites, then checking it on a webkit browser, having everything be broken and then spending hours trying to fix it.
What happens is that designers (and product managers) stress over minute details instead of seeing the bigger picture. So developers spend an obscene amount of time fixing iOS and Galaxy specific bugs that don't degrade the overall experience but instead aren't pixel-perfect.
And as a result most other devices simply aren't tested. And instead of allowing those devices to see the site (warts and all) they resort to a whitelist of devices that can see the (QA verified) mobile site while everyone else gets either a basic mobile html site or the desktop.
Yep, it's a browser vendor's reaction to a developer-tilted monoculture. On repeat.
On the plus side, User agent strings are moving closer to being useless as conditional branches for features. Hopefully, vendor-prefixes won't be far behind.
I guess developers just don't grok abstractions when it comes to the Web. They know their preferred browser, but somehow fall short of abstracting their development to "work on the Web" rather than "Works best in Chrome on an iPhone 5S."
This is just another reason why all browsers (not just mobile) should be reporting their screen size. As in, the actual height/width. Not pixels. Pixels lie and so do browsers, actually.
If I knew that the user's browser was 3 inches wide I could choose a point-based font size that's appropriate. It would also be trivially easy to scale font and image sizes up or down based on that knowledge. Especially if I'm using SVG.
72pt is precisely 1 inch tall (width is variable). However, if I set a font to 72pt we'll see that almost all browsers get it wrong. They are hard-coded to assume that the user's display is 96dpi or even worse (in the case of Apple devices) it simply pretends that the device is some fixed pixel width when it isn't (i.e. retina displays).
Did you know that the CSS spec has 'in' and 'mm' as size options? Yet when you set the font-size to '1in' you will almost never get a font that is one inch tall because the browser is hard-coded to assume that the user's display is 96dpi. It drives me crazy and it will only get worse over time as we get a larger variety of devices.
We need to stop the madness (that was introduced by Apple with the pretend-the-screen-has-this-many-pixels nonsense) and switch to accurate screen size/dpi reporting. Anything else is doomed to crap like what's mentioned in this article.
What does the browser in an Oculus Rift report? What about the projector on my wall?
Perhaps we're more interested in angular sizes, and then possibly pixel densities (again in terms of angular size) in case we need to worry about font legibility etc.
> The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
You would also need distance from the user's eyeballs. This is especially important for screens that can be significantly closer or farther from the user depending on the use case. See Google Cardboard. See also larger monitors that could be used as lean-back television displays in dorm rooms.
> This is just another reason why all browsers (not just mobile) should be reporting their screen size. As in, the actual height/width.
That's completely useless, 1cm on a mobile device and 1cm on a desktop are not the same for a user, to say nothing of 1cm on a TV screen, an Oculus Rift (where would you even measure size there?) or a projector (which would require a rangefinder for precise estimation and will probably vary slightly over the whole surface, won't that be fun?)
> Not pixels. Pixels lie and so do browsers, actually.
And you'd expect them to lie less for "physical dimensions"… why?
> Did you know that the CSS spec has 'in' and 'mm' as size options? Yet when you set the font-size to '1in' you will almost never get a font that is one inch tall because the browser is hard-coded to assume that the user's display is 96dpi. It drives me crazy and it will only get worse over time as we get a larger variety of devices.
Before suggested that others read the CSS spec, you may want to do so yourself:
> For lower-resolution devices, and devices with unusual viewing distances, it is recommended instead that the anchor unit be the pixel unit. For such devices it is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel.
> The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm's length, 1px thus corresponds to about 0.26 mm (1/96 inch).
> We need to stop the madness (that was introduced by Apple with the pretend-the-screen-has-this-many-pixels nonsense)
That's not going to happen. Every time some schmuck advocates "practicality > purity" somebody down the road will have to support their "practical choice" and you end up with virtual pixels because all content is completely broken if you use actual physical pixels.
You lost me. How is 1cm on a mobile device not the same as 1 cm on a desktop. Yes, they have different pixels resolutions within that centimeter, but the length of a centimeter doesn't change.
Well, unless the engineers are fudging the standard so marketing isn't seen to be lying.
> You lost me. How is 1cm on a mobile device not the same as 1 cm on a desktop.
That's because you stopped there and didn't read the rest of the phrase.
> Yes, they have different pixels resolutions within that centimeter
That's not relevant in any way, shape or form, the issue would exist even if all devices had the exact same pixel density.
> the length of a centimeter doesn't change.
The length of a cm doesn't change, but what you can do with it changes a lot due to different viewing distances: a cm at 20cm, a cm at 80cm and a cm at 3m are very different visual beasts, and so are a cm manipulated using fat fingers, a mouse, a stylus or some sort of laser/ir pointer.
It's worse than that, there's the visual effect from angular size and the "manipulative" effect from interaction device.
For instance, because it's used with fat and impressive fingers a smartphone held close to your face (and thus with a high angular size for its physical size) needs to provide much bigger controls (in both angular and absolute terms) than a desktop computer manipulated through a mouse.
And of course this isn't linear as manipulating e.g. a Wii through its remote is also very impressive.
Good. UserAgent-based feature detection needs to be broken every few years as it is a gross abuse (Aggravation; like Rant)
I'm blown away people see this and react with "if we had more of a singular monoculture, this wouldn't be an issue", when the exact opposite is true. Making it difficult/near impossible for newcomers/outliers to operate in the browser space is very unlikely to improve things in the long run.
I'm sure Opera had many reason to cave in and throw away their rendering engine in favor of a webkit fork, but I suspect having to continuously swim upstream against the ever growing proprietary extensions and broken browser detection logics out there might have played a role.
-webkit prefixes are supposed to stash away experimental features until they get standardized, but with the webkit monoculture, they become de facto standard as their implementation trickle through the webkit forks and releases. That's harmful.
Perhaps having faster standard tracks where prefixed features don't have time to become second nature for webdevs, and fostering a culture of "proprietary prefixes don't belong in production code" could help here.
This is a symptom of the ecosystem's indifference to the windows phone platform.
Browser vendors implementing hacks to trick web apps into presenting the right content because web developers have learned that they can't rely on the browser to render content properly.
I think there's a lesson in here about treating your ecosystem right.
IIRC you can't run a HyperV image inside a Parallels VM because it doesn't have access to the Intel extensions it needs. You could do it via Bootcamp, though.
If I remember correctly, Apple had that same exact problem in pre-iPhone and pre-Chrome days. AFAIK this was why they released Safari on Windows- to allow devs to test on Safari without requiring a mac.
At least they are accepting it and acting accordingly to where they stand in terms of market share. If you have low single digits of share, this is what you need to do to keep up.
Microsoft invented user agent lying when MSIE 2.0 started advertising itself as Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), so we known exactly where that road goes.
Even though sites should be using the standards version the Apple one is still very popular. If you decide not to support it, users just think your OS / Browser looks like crap. It's a tough spot to be, especially considering that its financially in Apple's best interest to break the web.
"In general, our advice is to develop a responsive site that can adapt to the capabilities of different devices. If you choose to build a mobile-specific experience then we recommend looking for the sub-string "mobile" in the user agent string to determine when to deliver mobile optimised content:"
function isMobile() {
return navigator.userAgent.toLowerCase().indexOf("mobile")>=0;
}
This is really the best we can do after twenty years of the WWW?
Browser identification is an arms race. It harkens back to the original user agent wars near the turn of the millenium. I think it's unlikely to ever have a solid way to identify browsers. If one is developed, it will be used by (bad?) developers as an exclusion check for their fancy content. That gives other browsers an incentive to lie. I think the whole concept is inherently unstable for this reason.
Although I agree for the -webkit prefix implementation (this can cause no harm to the render of the web page), I disagree strongly with tweaking the user-agent.
There's some features that simply cannot be tested with feature detection (the HTML5 Appcache and the tel:// URI scheme to name two of them but I'm sure there's more) and tweaking the user-agent might also break some web pages.
I run a website in production where I test for the Chrome & Firefox user-agent to enable the appcache. I'm not saying that IE does not have any support on it (it's actually supported), it's just that I don't have the time to test fully the IE implementation to make sure that the user will have a web page that will be updated properly. So IE will still work but without any appcache (which is not a real issue).
If they change their user-agent and their implementation of the feature is not 100% perfect, the website might not work properly.
Firefox OS has a Web Compatibility program [0] where they work with the webmasters of the Alexa Top 1000 Sites to achieve 90% compatibility for the mobile content sent to Firefox for Android and Firefox OS. They use the website http://arewecompatibleyet.com/ to check how far they've come along. The Firefox OS user agent is very simple:
Yeah, I really don't understand the Firefox OS comparison. They stress that IE is now compatible with popular websites, but they don't do a comparison with the popular browsers...
Because a ton of people ~5 years ago decided to do entirely separate mobile sites instead of responsive designs and we have now ended up with the mess everyone said we'd end up with.
Some websites have tailored a completely optimized experience for mobile. For example, if homedepot.com detects your device as "mobile", it will redirect to http://m.homedepot.com/ otherwise it will show content from http://www.homedepot.com/. Try it on your mobile device versus desktop and see what happens.
How exactly is the mobile web biased towards iOS? I've rarely (if ever) had to use a vendor prefix when developing for mobile. I am using Bootstrap, so maybe they're doing those for me.
Because some websites use user agents to determine whether or not to serve a website optimized towards modern mobile devices, and some of those user agent sniffers are only looking for Mobile Safari. If you aren't Mobile Safari or claiming to be, you either get the desktop site or the ancient mobile site designed for feature phones.
Isn't this basically the state of the User Agent strings across all browsers? The strings are a messy combination of different browsers, versions and rendering engines.
It's silly that all the anti-IE comments are being downvoted. IE8, 9, 10 and 11 are still complete shit and the debug tools are even worse. Microsoft talks a good game about implementing all these standards but I experience bugs regularly in Trident, even when I was developing something specifically for it a few months back. It's a completely primitive and glitchy browser that doesn't need to exist.
Firefox has had its problems too recently, but at least it's open source and they're trying. Microsoft has literally nothing going for them on this front.
The world doesn't need Trident. The case for IE being mandatory in the OS died years ago, and the new direction Microsoft talks about taking embraces open source.
A Microsoft backed browser that ran WebKit (or even Gecko) would give their team a much stronger platform to stand on when discussing standards. It would also close the door on one of Microsoft's biggest black eyes; the stagnation of the web in the early 2000's because of IE.
Mozila/5.0 (Mobile; Windows Phone 8.1; Android 4.0; ARM; Trident/7.0; Touch; rv:11.0; IEMobile/11.0; NOKIA; Lumia 625) like iPhone OS 7_0_3 Mac OS X AppleWebKit/537 (KHTML, like Gecko) Mobile Safari/537
---
Sounds pretty desperate. But this is Microsoft with Windows Phone, so, no surprises here...
This wasn't immediately clear to me as well. From what I can see, they just mirrored their change in IE11 desktop and added "like Gecko" to the end of it.
The title is almost always changed if the post's title is different from the submission's title. There usually isn't a good reason to editorialize the title when submitting to HN, unless the title is something like a "Show HN."
For anyone seeing this comment after the title has been changed, OP's title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly"
> For anyone seeing this comment after the title has been changed, OP's title was "Windows Phone's IE starts masquerading as mobile Safari to render pages properly"
editorializing or not, i prefer the less vague title. serves as a great tldr;
The simple fact is that it works better for Windows Phone users. If developers hadn't been using webkit-prefixed CSS everywhere it wouldn't be an issue, but it is.
That said, I wish Windows Phone IE had better developer tools. Both Android and iOS let you plug your phone in via USB and access the web console. It's great.