How many years have rags like the Register dug into the numbers and predicted Microsoft's demise?
Unfortunately this doesn't seem to work well, even in Windows 10. On my retina Macbook Pro, I'm running W10 in a VM and it defaults to around 200% DPI. But the Start Menu and its text are small. Other areas have mixtures of small and large pieces. It's kind of a mess and Microsoft would do well to clean that up before release.
It's a mess because there are size settings for only 6 UI element types: title bars, menus, message boxes, palette titles (WTF is this?), icons, and tooltips.
There should be settings for list row height, dialog button height, etc. I could have sworn older versions of Windows let you do this.
So your complaint is that, while Explore can zoom its file icons, it failed to zoom its file name. You are frustrated with smaller text specifically inside the Explore (not the entire system), because it will be harder to rename the file name as the text isn't finger friendly as the giant icons you have zoomed so close. Am I right?
No, my complaint is that it's not really zoom at all. The primary action of the mouse wheel is to scroll through the different views. The secondary action is that when you're on one of the icon views, the icon size changes. That's not zooming either.
I thought you wanted the tree to be zoomed because you said "Also, why can't the tree view in the left pane also zoom? It would work great as a UI paradigm for touch, but the nodes are too damn small". But, that's ignore that subject for now because I have yet to see anyone doing it.
Yes, and I still do. You asked for an example of programs that allowed content to zoom, and I gave you this list. You came back and said VS doesn't allow treeviews to zoom, which is irrelevant to the original point.
I wasn't saying Explore doesn't need to be more friendly with different input devices. I agree on the problem.
I was only challenging your solution to the problem. Having two zooming styles side-by-side will only confuse the user. The likelihood of proper usage is low. It will only be acted based on single zoom gesture or mouse wheel action.
What two styles? I'm saying that there should be one style. The mouse wheel should zoom--period. It should not scroll through the different view types as it currently does. If I want a different view type, I'll just click it. I don't need to scroll through them to find a view that I like. What I do want to do is resize the content within a particular view.
The user will only use the default action of the gesture. Foe example, the most intuitive behavior is zooming it like anything else. Meaning the layout is the same as the text and icon size increase. So, most user would never know how to change layout. If someone changed the layout, they would stuck with that layout.
Changing the view should be done the way most people currently do it--by clicking the menu in the ribbon. There should be a dropdown for the zoom level in the ribbon too, but it should also be changeable through mouse wheel or pinch to zoom like most applications allow.
The double zooming style is confusing. That has already happened in old IE with text size (not zoom). I have set to see other apps implemented duel zoom style as well.
In IE, there are both text size and zoom options because of the way HTML works. Changing the text size will resize all of the HTML elements with CSS styles that have dynamic property values (em or %). If the styles have static values (px or pt), they won't change at all. Zoom, OTOH, will resize all of the content proportionally regardless of the CSS properties. That is what I'm saying File Explorer should allow.
These "two styles" are unique to browsers, and it's irrelevant to anything else.
And even then, forget about user confusion, the rest of the system is having smaller text. Hell, the zoom level maybe localized to single folder path. And the rest of the GUI is still tiny.
The ribbon interface scales just fine with the menu size settings in the control panel. You can find a happy medium for both mouse and touch. The problem is the content area--the folder view pane and the navigation pane. The text size is controlled by the icon size setting in the control panel, but nothing else is. The row heights stay the same as do the checkboxes.
This obviously needs to be fixed, but being able to zoom in and out is still very useful. You may want to zoom out to get a better view of the types of files in the folder. Then you may want to zoom in to select, rename, change properties, etc. of a particular file or a small group of files. This is a nicety that could be appreciated by mouse+keyboard users as well.
Might as well just make DPI to 300% and get it over with if you want everything to be finger friendly using the existing Explore and rest of the system.
No, that's exactly the lazy solution that Microsoft advocates right now. If you go to any Microsoft store all of the Surface Pro 3s are set to 150% scaling which means that you're losing 33% of the real estate afforded by the display.Like I said, I want the Explore to be finger friendly as a whole. But, evolving the Explore directly would just always be half assed and making desktop people angry.
I prefer them just make metro version, keep adding features along the way to match the desktop version. And finally once everyone is happy with using metro version, we can replace the old Explore entirely.
No, it doesn't have to be half-assed. What I'm advocating is making it more flexible so that the user can use multiple input modes without having to use two entirely different applications. This binary way of thinking is exactly what the OP is complaining about.
Just incase it was lost: I wasn't claiming that the other browsers get some different/better Google than IE9,10,11. I'm assuming here that other browser have more configurability (no need to set up a proxy or write C++) if you wanted to send a different user agent to a specific site.
You can change the user agent string through the F12 developer tools. No need to write C++ code.
Where did I say VS had a tree view that zoomed? I don't believe I ever said that VS was exactly as I wanted File Explorer to be.
To recap, this is what I said:How about starting with the zooming of content like every other application that supports zooming does?
All of the apps you listed only did one zooming style. Explore has one zooming style as well.
The "zooming style" is a half-assed implementation of what people expect from zooming content. The mouse wheel just scrolls through the different views. The mouse wheel scroll does scroll through some intermediate views between the different icon views (extra large, large, medium, small) that render the icons in different sizes, but the text doesn't ever change size. For something called a "File Manager", the "content" should be the most important file characteristics (file name, size, date, etc.), which are all represented as text. Yet, this "content" can't be zoomed at all.
All of the apps you listed only zoom in the content page, not something like tree view you desired.
Does this matter? File Explorer is part of the OS, so it should be even more capable of supporting the different input modes since the OS needs to contemplate those input modes.
With the launch of the Surface Pro 3 in late June, we've finally got a full quarter of Surface revenue that includes Microsoft's latest tablet. While Surface sales are still a mystery, Surface revenue was $908 million this quarter, up a massive 127 percent from the $400 million this time last year.
That's a pretty solid increase in sales, whatever the units might be.Microsoft sold 9.3 million Lumia phones in the most recent quarter, a 5.6 percent increase from the record 8.8 million handset sales in the same period last year.
That's about 25% of the number iPhones sold in the quarter. Plus, there have been several new OEMs bringing WP devices to market in the last quarter. When we start talking of iPhone unit sales as being only 4x or lower of WP sales instead of 10x or 20x, it bodes well for the platform. It's becoming a platform that can no longer be ignored by developers.
@fanbaby: I'm not sure what you're so impressed by:
I think I prefer Bing's results in this case. 3 links to IMDb quotes aren't very useful, whereas the two links to the Wikipedia articles are.