The fewer changes there are from the app on your phone to the desktop to the Xbox and so on, the easier it will be for users to discover how to use your app when moving from one device to the next.
Unfamiliar users do much better when the user interface matches the device being used. If you have a mouse in your hand, you look for the start button or the apple menu. You expect deep menus with lots of functionality, that take dexterity to choose the right item. Much power is at your fingertips. Years and years of drill have pounded this into us.
When you are pointing with a finger, it's different. You don't have the dexterity to choose a single item from a deep complex menu. I could go on and on...
Microsoft already thought about that. For example, context menus can adapt their size to the input method being used. If using a mouse or stylus, the menu uses shorter items, and when using a touch screen (tap-and-hold), the menu uses larger items. In fact I just tested that on the latest build of Windows 10, no reboots or mode changes were needed, it just worked one after the other.
The web has expanded its functionality to the point where you don't even need an app for most things. All you need is to surf there in your web browser, phone or desktop.
That statement applies just as much to any program. Web apps are useful for many things, but they haven't quite replaced all native applications yet for several reasons. Native apps run faster, have more access to device capabilities, and do not inherently require Internet access or use up your data plan.
If you are writing an enterprise app and you think you need a custom client application, you are probably not doing it wrong.
That statement is blatantly absurd. You must not have experience in the enterprise.
The trouble is that different situations require different sorts of application designs. Mouse/keyboard and touchscreen are not even remotely equivalent; different things work better or worse on each. Small screens require very different tradeoffs from larger screens or multiple screens.
The universal platform is built with all of that in mind. As the developer, you can respond to all the various input methods that you want to support. Apps are responsive, like web apps, so that the developer controls how each app conforms to the screen size and capabilities of the device.
The more consistent you make your UI between your target device families, the easier it will be for users to approach your application.
You cant just take a desktop program and slap it on a phone
No, it's taking a universal app and slapping it both on the desktop and phone, as well as Xbox, HoloLens, etc.
The app can easily conform to the size available, similar to responsive websites. (This is nice even on the desktop, because sometimes I'd like my app to work well if I make its window small... so it adjusts accordingly.) Universal apps can easily support various input methods including keyboard, mouse, touchscreen, Xbox controller, and so on.
The bigger issue, and the 500 lb gorilla in the room is that to publish "Universal apps", devs have to go through MS! MS gets to be the gatekeeper, deciding if your app even gets to be published. MS also gets 30% of the gross revenue. "Universal apps" are ONLY available through Microsoft Windows Marketplace.
Completely wrong. Users can sideload universal apps in Windows 10, they just need to enable the Developer Mode setting.
I don't know about a posse, but I don't think it's any surprise that getting one of the first posts (and especially a top-level post) will get you to +5 much faster than if you post further down (such as this level). People see those posts earlier and are more likely to mod them.
Also... I haven't tried to pinpoint when it happens, but sometimes I notice anything below a 3 gets hidden automatically on my view... unless they are at the top level, in which a 2 will suffice.
The system I mentioned, the one ending in 1971, was Bretton Woods. It was not the kind of gold standard where gold was treated the same currency. Nevertheless, currency was convertible to gold at a fixed rate, which is as far as the relevance here is concerned.
While we can buy better stuff now for the same inflation-adjusted cost, that isn't going to close the gap.
As I said before: "The gap may very well exist, but this chart doesn't show it." So far, I haven't seen data that shows evidence to support this chart's claim that such a gap actually exists.
I've been trying out the various Technical Previews over the past few months and I'm not surprised that they've pulled the plug on this. There's no way it was going to be ready by the target date of July 29.
They didn't kill their July 29 RTM date. They suspended new TP builds "briefly", specifically to switch over to using the production channels distribution channels. According to the quote, it sounds likely that they will resume TP builds prior to RTM.
Considering at one time they averaged 2 months between fast ring releases, any new TP release prior to RTM would be much faster.
And then there's all the pointless, useless "apps".
You think that is a recent phenomenon? It's been that way since Windows came into existence.
It's not that I disagree with you though, the Windows Store is full of crapps. Microsoft has specific plans to crack down hard on those, so I'm going to withhold judgment on the state of the Windows 10 Store until some time after RTM. Also consider that app capabilities will increase due to a larger API set of the UWP and the ability to put Win32 apps in the Windows Store (via Project Centennial).
the US was de facto off the gold standard much earlie.r If I can't conduct transactions in gold, and I couldn't back then, it isn't really a gold standard.
I don't think you understand how the gold standard worked. If the exchange rate was fixed between the US dollar and an ounce of gold, then we were using the gold standard. Whether most places of business accepted gold as currency is irrelevant.
You appear to be looking at inflation-adjusted wages and assuming that's productivity.
No, not at all. In fact, you just described the two lines on that chart, which are obviously not the same.
What I am saying is:
1) the chart is misleading (particularly the "real wages" line), and 2) you can't make a meaningful comparison between the two without additional information, such as quality of life.
Likewise, job ads, ideally, would be shown to the best candidates, not necessarily the users most likely to click them
Ideally for whom? For Google, the ideal is "whatever makes the most money for us". Ad clicks = money.
HR is drowning in bullshit resumes as it is. Ads that produce more bullshit resumes from unqualified candidates who click/submit on everything will not be worth much to any company.
Most users don't provide their résumé to Google. So Google is left to collecting the data that users actually provide... things like demographic data from social media profiles and browsing data. Algorithms take this data as input, and produce as output the ads that are more likely to be clicked by each user.
If you want to improve Google's ability to find the best people for a particular ad, then Google needs to collect and use more data.
But consider that this study was done by providing new (fake) users, and only telling Google the gender. Google used that information, but according to you this is wrong. So, the only thing Google could have done in this situation is to ignore gender. But then that would be at odds with collecting and using more data. That's a contradiction.
Google can either improve ad targeting by collecting and using more data, or be more "fair" by using less data, but you can't have both because those goals are in contradiction.
Without your pure speculation that the click through is what is driving the difference, all you're left with is an insinuation by the output of Google's algorithm that men are six times more likely than women to be good candidates for highly paid jobs
Which is also pure speculation. Based on Hanlon's Razor, "never attribute to malice that which is adequately explained by stupidity", I prefer my version of speculation.
That's not even the latest stable version of gedit.
The text editing (the point of the application) looks pretty close to identical in old and new. The only big difference is the menu and toolbar area, which reduces--in version 3.16--the size of the area above the text editor by 67% in exchange for putting the lesser used functions behind a menu.
It might not fit your fancy, and that's perfectly fine. But others prefer that the UI get out of the way instead of always being in your face... evidently they won, this time.
As cars become more automated, they will collect real-time data in order to perform those capabilities.
The cars may also pass some of that data along to other vehicles and/or stationary systems to better provide advanced warning of traffic and environmental conditions.
But archiving that real-time data is the problem. Even if you aren't afraid of those entities you listed above, you can be well within reason to be concerned of what happens when someone figures out how to hack into that data stream. I'm very concerned that some database will link PII to car position, providing much more information on my physical presence than I would like to volunteer to anyone I don't know and trust.
Of course, that's not the fundamental issue... which is:
The turning driver has a green light right when pedestrians have the walk light
When your city can reasonably be ranked as the top pedestrian city in the world, it might behoove you to plan accordingly by not putting your pedestrians directly into oncoming traffic.
Slashdot Mirror
The fewer changes there are from the app on your phone to the desktop to the Xbox and so on, the easier it will be for users to discover how to use your app when moving from one device to the next.
Unfamiliar users do much better when the user interface matches the device being used. If you have a mouse in your hand, you look for the start button or the apple menu. You expect deep menus with lots of functionality, that take dexterity to choose the right item. Much power is at your fingertips. Years and years of drill have pounded this into us.
When you are pointing with a finger, it's different. You don't have the dexterity to choose a single item from a deep complex menu. I could go on and on...
Microsoft already thought about that. For example, context menus can adapt their size to the input method being used. If using a mouse or stylus, the menu uses shorter items, and when using a touch screen (tap-and-hold), the menu uses larger items. In fact I just tested that on the latest build of Windows 10, no reboots or mode changes were needed, it just worked one after the other.
The web has expanded its functionality to the point where you don't even need an app for most things. All you need is to surf there in your web browser, phone or desktop.
That statement applies just as much to any program. Web apps are useful for many things, but they haven't quite replaced all native applications yet for several reasons. Native apps run faster, have more access to device capabilities, and do not inherently require Internet access or use up your data plan.
If you are writing an enterprise app and you think you need a custom client application, you are probably not doing it wrong.
That statement is blatantly absurd. You must not have experience in the enterprise.
The trouble is that different situations require different sorts of application designs. Mouse/keyboard and touchscreen are not even remotely equivalent; different things work better or worse on each. Small screens require very different tradeoffs from larger screens or multiple screens.
The universal platform is built with all of that in mind. As the developer, you can respond to all the various input methods that you want to support. Apps are responsive, like web apps, so that the developer controls how each app conforms to the screen size and capabilities of the device.
The more consistent you make your UI between your target device families, the easier it will be for users to approach your application.
You cant just take a desktop program and slap it on a phone
No, it's taking a universal app and slapping it both on the desktop and phone, as well as Xbox, HoloLens, etc.
The app can easily conform to the size available, similar to responsive websites. (This is nice even on the desktop, because sometimes I'd like my app to work well if I make its window small... so it adjusts accordingly.) Universal apps can easily support various input methods including keyboard, mouse, touchscreen, Xbox controller, and so on.
The bigger issue, and the 500 lb gorilla in the room is that to publish "Universal apps", devs have to go through MS! MS gets to be the gatekeeper, deciding if your app even gets to be published. MS also gets 30% of the gross revenue. "Universal apps" are ONLY available through Microsoft Windows Marketplace.
Completely wrong. Users can sideload universal apps in Windows 10, they just need to enable the Developer Mode setting.
The official name today is Universal Windows Platform apps, or UWP.
It wouldn't be Microsoft if they didn't retire a good name the moment they found one that was worse.
But who needs a cure?
I don't know about a posse, but I don't think it's any surprise that getting one of the first posts (and especially a top-level post) will get you to +5 much faster than if you post further down (such as this level). People see those posts earlier and are more likely to mod them.
Also... I haven't tried to pinpoint when it happens, but sometimes I notice anything below a 3 gets hidden automatically on my view... unless they are at the top level, in which a 2 will suffice.
The system I mentioned, the one ending in 1971, was Bretton Woods. It was not the kind of gold standard where gold was treated the same currency. Nevertheless, currency was convertible to gold at a fixed rate, which is as far as the relevance here is concerned.
While we can buy better stuff now for the same inflation-adjusted cost, that isn't going to close the gap.
As I said before: "The gap may very well exist, but this chart doesn't show it." So far, I haven't seen data that shows evidence to support this chart's claim that such a gap actually exists.
I've been trying out the various Technical Previews over the past few months and I'm not surprised that they've pulled the plug on this. There's no way it was going to be ready by the target date of July 29.
They didn't kill their July 29 RTM date. They suspended new TP builds "briefly", specifically to switch over to using the production channels distribution channels. According to the quote, it sounds likely that they will resume TP builds prior to RTM.
Considering at one time they averaged 2 months between fast ring releases, any new TP release prior to RTM would be much faster.
And then there's all the pointless, useless "apps".
You think that is a recent phenomenon? It's been that way since Windows came into existence.
It's not that I disagree with you though, the Windows Store is full of crapps. Microsoft has specific plans to crack down hard on those, so I'm going to withhold judgment on the state of the Windows 10 Store until some time after RTM. Also consider that app capabilities will increase due to a larger API set of the UWP and the ability to put Win32 apps in the Windows Store (via Project Centennial).
You might want to look further than the first definition. The next two both use "in consideration of".
That might be a problem if this design language were only useful for tablets, but it isn't.
Command-line text editors are purely keyboard focused, and most don't display any type of toolbar or buttons.
So, you are saying that you are more likely to be misunderstood. Thanks for clarifying.
If I say, "In consideration of X, I believe Y," then you're saying essentially the same thing as, "Thinking about X has lead me to conclude Y."
Or it isn't, because that's not what I said.
Is the person who has trouble with language the one who utilizes accepted vocabulary, or the one who does not?
And what if I'm one of those users who needs that "lesser used" button every day, and multiple times an hour?
Welcome to the world of keyboard shortcuts.
I'm supposed to reduce my productivity because non-power users are afraid of buttons?
It's not about being "afraid" of buttons. It's about maximizing your focused task and getting everything else out of the way.
The thing I'm most afraid of is actually this opposite extreme, this.
Even your own definition of "in consideration of" has the same implication.
No, it doesn't. "In consideration of" implies only that something has been considered, not that it is a cause.
the US was de facto off the gold standard much earlie.r If I can't conduct transactions in gold, and I couldn't back then, it isn't really a gold standard.
I don't think you understand how the gold standard worked. If the exchange rate was fixed between the US dollar and an ounce of gold, then we were using the gold standard. Whether most places of business accepted gold as currency is irrelevant.
You appear to be looking at inflation-adjusted wages and assuming that's productivity.
No, not at all. In fact, you just described the two lines on that chart, which are obviously not the same.
What I am saying is:
1) the chart is misleading (particularly the "real wages" line), and
2) you can't make a meaningful comparison between the two without additional information, such as quality of life.
Likewise, job ads, ideally, would be shown to the best candidates, not necessarily the users most likely to click them
Ideally for whom? For Google, the ideal is "whatever makes the most money for us". Ad clicks = money.
HR is drowning in bullshit resumes as it is. Ads that produce more bullshit resumes from unqualified candidates who click/submit on everything will not be worth much to any company.
Most users don't provide their résumé to Google. So Google is left to collecting the data that users actually provide... things like demographic data from social media profiles and browsing data. Algorithms take this data as input, and produce as output the ads that are more likely to be clicked by each user.
If you want to improve Google's ability to find the best people for a particular ad, then Google needs to collect and use more data.
But consider that this study was done by providing new (fake) users, and only telling Google the gender. Google used that information, but according to you this is wrong. So, the only thing Google could have done in this situation is to ignore gender. But then that would be at odds with collecting and using more data. That's a contradiction.
Google can either improve ad targeting by collecting and using more data, or be more "fair" by using less data, but you can't have both because those goals are in contradiction.
Without your pure speculation that the click through is what is driving the difference, all you're left with is an insinuation by the output of Google's algorithm that men are six times more likely than women to be good candidates for highly paid jobs
Which is also pure speculation. Based on Hanlon's Razor, "never attribute to malice that which is adequately explained by stupidity", I prefer my version of speculation.
"In light of" is defined to mean "in consideration of". There's no need for correction.
Public opinion of deepwater drilling barely budged during the ordeal; today, a majority of Americans favor doing even more of it.
In light of all the rockets that have exploded and astronauts killed over the years, I favor doing even more space exploration.
Just because something is unsafe, doesn't mean I want to stop doing it. Sometimes it's worth doing so long as it can be done more safely.
Just look at what GNOME has done to gedit. It's hard to believe it, but gedit is a text editor! You wouldn't know it based on its now-fucked-up UI, though. It wasn't always like that. Gedit used to have a very good UI, before it was ruined.
That's not even the latest stable version of gedit.
The text editing (the point of the application) looks pretty close to identical in old and new. The only big difference is the menu and toolbar area, which reduces--in version 3.16--the size of the area above the text editor by 67% in exchange for putting the lesser used functions behind a menu.
It might not fit your fancy, and that's perfectly fine. But others prefer that the UI get out of the way instead of always being in your face... evidently they won, this time.
As cars become more automated, they will collect real-time data in order to perform those capabilities.
The cars may also pass some of that data along to other vehicles and/or stationary systems to better provide advanced warning of traffic and environmental conditions.
But archiving that real-time data is the problem. Even if you aren't afraid of those entities you listed above, you can be well within reason to be concerned of what happens when someone figures out how to hack into that data stream. I'm very concerned that some database will link PII to car position, providing much more information on my physical presence than I would like to volunteer to anyone I don't know and trust.
Of course, that's not the fundamental issue... which is:
The turning driver has a green light right when pedestrians have the walk light
When your city can reasonably be ranked as the top pedestrian city in the world, it might behoove you to plan accordingly by not putting your pedestrians directly into oncoming traffic.
Like Clojure? That's a cool name. It's like "closure" but with a J. But let's not talk about functional programming, that's icky.
And best thing, nobody even has to know it is LISP! Parenthetically speaking, of course.
Understood, it wouldn't be for everyone. Then again, dying from a survivable crash isn't for everyone either.
Meanwhile, your post is not insightful at all.