You want an example of a useless site in iOS7? Maps.Google.com. So much of the screen is menu, its worthless. I guess they want you to use their app. (Yeah, I blame Google).
Nokia you make me sick. iOS7 hurt Here's user experience? Really? So why didn't you clowns update that b**** like a boss. Oh, cause you can't do software!!!!!!!!!!!
Nokia's excuse is pretty weak. The Here Maps app is a simple HTML5 wrapper. I can't imagine that it needs a great deal of updating to make it iOS7-compliant. I think this is Nokia's way of saying "No-one is using our shitty app so let's stop supporting it".
Quote:
Originally Posted by Rogifan
Why is iOS 7 bad for developers?
In general, it's not for most developers. However, my experience is that the SDK is a hell of a lot buggier than previous releases. There's bugs that I've reported in the v7.0 betas that still aren't fixed in v7.1.
Nokia can't do software. Simple. This is why their smartphone business died.
No, the latter doesn't necessarily follow the former. Apple can't do software worth a damn and yet their smartphone business is doing great. It apparently takes more than poor software to sink a smartphone ship.
I've owned one Nokia phone in my life. It was the worst user experience of just about any device I have ever owned.
The phone was so bad that even turning up the incredibly low volume was major problem, conveniently left unexplained in the so-called instruction manual. I had to do a web search to find the answer and it wasn't found on Nokia's site.
I have vowed to never buy another device from that company.
Good question. Well for one thing, to remain backwards compatible with iOS 6, it requires code that's not very flexible. For instance, the meaning of "tintColor" is now different in iOS 7 than in everything else in iOS (6.1 and earlier). Setting a tintColor on a navigation bar would change the background color of the bar while applying the gradient. To do that now, all references have to be set to "barTintColor" or other depending on the view. The tintColor property now refers to the color of text and icons in the bar and cascades through the view hierarchy.
The app I develop is for musicians and used on-stage. We've experimented with different designs and found that large touch zones and bold/large text is important for proper usability. iOS 7 reinforces what I feel is bad design language for this scenario... light typefaces, small text labels that don't appear as buttons and thin icons. All of this combines into what a lot of my users refer to as "unusable" given the situation they use the app. I haven't updated the UI of my app because I'm working on a complete UI redesign anyway, but from initial focus group tests, iOS 7 fails in that regard. I'm not sure if deviating from the style guide will cause issues.
It's also littered with bugs (still). I've had to workaround a number of issues that are caused by threading concurrency. For instance, I need to load a UIWebView on both the main screen and an external screen. Doing this in iOS 7 causes one of the UIWebViews to not render and it's not predictable. The only way I can force this to work is to delay the drawing of the external display by a second or two. This is bad programming practice, but it appears that running more than one UIWebView at once will cause issues. I'm experiencing bard crashes when display Word DOCX files. This is due to a read error deep in the iOS codebase and not something that can be worked around. There are some bugs regarding underlines text in NSAttributedString, poor performance and dropped packets in GKSession (GameKit Framework) and more.
Now, if I were coding an app from scratch and not supporting non iOS 7 devices or weighed down by these legacy features, I'm sure things would not be as "bad"... but I'm trying to maintain a user base, 15% of which use iOS 5.1 (iPad 1) and 15% of which use IOS 6. Shockingly, about 60% are using iOS 7 at this point.
So, I'm redesigning the app. What does that mean? It means recreating ALL of my tutorial videos, help documentation, screenshots and more... in 14 different languages. Bad for developers is thousands of dollars worth of rework because Apple wants my app to fit in. All this while I'm working on a 2.0 version where I have to do that anyway.
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.
... Nokia's representative did not elaborate on exactly what changes the Scandinavian company's maps unit disagreed with.
Really? Then let's do a little reading between the lines, shall we?
Originally Posted by AppleInsider
... Here Maps first hit the App Store in November of last year in the turbulent aftermath of Apple's flawed in-house mapping service rollout.
Apple has worked long and hard to fix the problems with their own Maps app. And now it's better than Here Maps ever was. And now nobody uses Here Maps. So Nokia has nothing to lose by removing it from the App Store and nothing to gain by leaving it on the App Store.
Originally Posted by AppleInsider
... Here Maps was not included in the takeover and is now one of Nokia's largest remaining business units.
Evidently it wasn't good enough for Microsoft to assimilate into Bing Maps. And yet it's still one of "Nokia's largest remaining business units." You'd think that Nokia would make sure that their large remaining business units would be successful, make money for the company, and all that stuff. Or maybe they're shopping it around to other tech companies. Who knows?
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.
Hear, hear. A lot of people on here don't understand the difficulties of software development and are very quick to insult developers.
Good question. Well for one thing, to remain backwards compatible with iOS 6, it requires code that's not very flexible. For instance, the meaning of "tintColor" is now different in iOS 7 than in everything else in iOS (6.1 and earlier). Setting a tintColor on a navigation bar would change the background color of the bar while applying the gradient. To do that now, all references have to be set to "barTintColor" or other depending on the view. The tintColor property now refers to the color of text and icons in the bar and cascades through the view hierarchy.
The app I develop is for musicians and used on-stage. We've experimented with different designs and found that large touch zones and bold/large text is important for proper usability. iOS 7 reinforces what I feel is bad design language for this scenario... light typefaces, small text labels that don't appear as buttons and thin icons. All of this combines into what a lot of my users refer to as "unusable" given the situation they use the app. I haven't updated the UI of my app because I'm working on a complete UI redesign anyway, but from initial focus group tests, iOS 7 fails in that regard. I'm not sure if deviating from the style guide will cause issues.
It's also littered with bugs (still). I've had to workaround a number of issues that are caused by threading concurrency. For instance, I need to load a UIWebView on both the main screen and an external screen. Doing this in iOS 7 causes one of the UIWebViews to not render and it's not predictable. The only way I can force this to work is to delay the drawing of the external display by a second or two. This is bad programming practice, but it appears that running more than one UIWebView at once will cause issues. I'm experiencing bard crashes when display Word DOCX files. This is due to a read error deep in the iOS codebase and not something that can be worked around. There are some bugs regarding underlines text in NSAttributedString, poor performance and dropped packets in GKSession (GameKit Framework) and more.
Now, if I were coding an app from scratch and not supporting non iOS 7 devices or weighed down by these legacy features, I'm sure things would not be as "bad"... but I'm trying to maintain a user base, 15% of which use iOS 5.1 (iPad 1) and 15% of which use IOS 6. Shockingly, about 60% are using iOS 7 at this point.
So, I'm redesigning the app. What does that mean? It means recreating ALL of my tutorial videos, help documentation, screenshots and more... in 14 different languages. Bad for developers is thousands of dollars worth of rework because Apple wants my app to fit in. All this while I'm working on a 2.0 version where I have to do that anyway.
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.
If you only support iOS 7, you'll find that 100% of your user base can use the app.
Nokia had plenty of time to update the app for iOS 7. Its failure to do so is its own fault.
It did not receive a single update the whole year that it was on the app store... The only point for that app was just to poke fun at Apple Maps and nothing else...
Comments
You want an example of a useless site in iOS7? Maps.Google.com. So much of the screen is menu, its worthless. I guess they want you to use their app. (Yeah, I blame Google).
Who's Nokia?
So why didn't you clowns update that b**** like a boss.
Oh, cause you can't do software!!!!!!!!!!!
Nokia's excuse is pretty weak. The Here Maps app is a simple HTML5 wrapper. I can't imagine that it needs a great deal of updating to make it iOS7-compliant. I think this is Nokia's way of saying "No-one is using our shitty app so let's stop supporting it".
Quote:
Why is iOS 7 bad for developers?
In general, it's not for most developers. However, my experience is that the SDK is a hell of a lot buggier than previous releases. There's bugs that I've reported in the v7.0 betas that still aren't fixed in v7.1.
And that overall blue tone to the app is just horrible looking. Even if the mapping was good, there is no way I could bear to use that ugly app.
That being said, it is hard to figure out what Nokia means by saying its apple's fault. Doesn't make much sense even if you trust them completely.
More like bitter pill.
The universe's savior when it comes to user experience.
Errors on TomTom's POI database are also Apple's fault.
They didn't want to meet Apple's guidelines for optimizing for iOS 7 by the deadline.
Nokia can't do software. Simple. This is why their smartphone business died.
No, the latter doesn't necessarily follow the former. Apple can't do software worth a damn and yet their smartphone business is doing great. It apparently takes more than poor software to sink a smartphone ship.
Unless, of course, you were utterly wrong, in which case the ship isn't sinking because the software is just fine.
The great news is that Nokia now has been provided with an excellent opportunity to show the world how they think things should really be done.
Expect great things shortly.
Less Nokia. More Yeskia.
I've owned one Nokia phone in my life. It was the worst user experience of just about any device I have ever owned.
The phone was so bad that even turning up the incredibly low volume was major problem, conveniently left unexplained in the so-called instruction manual. I had to do a web search to find the answer and it wasn't found on Nokia's site.
I have vowed to never buy another device from that company.
You serious? Why haven't they shown us before?
You serious?
Not at all.
The only thing that Nokia is likely to show us in the future is their impression of Blackberry.
Good question. Well for one thing, to remain backwards compatible with iOS 6, it requires code that's not very flexible. For instance, the meaning of "tintColor" is now different in iOS 7 than in everything else in iOS (6.1 and earlier). Setting a tintColor on a navigation bar would change the background color of the bar while applying the gradient. To do that now, all references have to be set to "barTintColor" or other depending on the view. The tintColor property now refers to the color of text and icons in the bar and cascades through the view hierarchy.
The app I develop is for musicians and used on-stage. We've experimented with different designs and found that large touch zones and bold/large text is important for proper usability. iOS 7 reinforces what I feel is bad design language for this scenario... light typefaces, small text labels that don't appear as buttons and thin icons. All of this combines into what a lot of my users refer to as "unusable" given the situation they use the app. I haven't updated the UI of my app because I'm working on a complete UI redesign anyway, but from initial focus group tests, iOS 7 fails in that regard. I'm not sure if deviating from the style guide will cause issues.
It's also littered with bugs (still). I've had to workaround a number of issues that are caused by threading concurrency. For instance, I need to load a UIWebView on both the main screen and an external screen. Doing this in iOS 7 causes one of the UIWebViews to not render and it's not predictable. The only way I can force this to work is to delay the drawing of the external display by a second or two. This is bad programming practice, but it appears that running more than one UIWebView at once will cause issues. I'm experiencing bard crashes when display Word DOCX files. This is due to a read error deep in the iOS codebase and not something that can be worked around. There are some bugs regarding underlines text in NSAttributedString, poor performance and dropped packets in GKSession (GameKit Framework) and more.
Now, if I were coding an app from scratch and not supporting non iOS 7 devices or weighed down by these legacy features, I'm sure things would not be as "bad"... but I'm trying to maintain a user base, 15% of which use iOS 5.1 (iPad 1) and 15% of which use IOS 6. Shockingly, about 60% are using iOS 7 at this point.
So, I'm redesigning the app. What does that mean? It means recreating ALL of my tutorial videos, help documentation, screenshots and more... in 14 different languages. Bad for developers is thousands of dollars worth of rework because Apple wants my app to fit in. All this while I'm working on a 2.0 version where I have to do that anyway.
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.
... Nokia's representative did not elaborate on exactly what changes the Scandinavian company's maps unit disagreed with.
Really? Then let's do a little reading between the lines, shall we?
... Here Maps first hit the App Store in November of last year in the turbulent aftermath of Apple's flawed in-house mapping service rollout.
... Here Maps was not included in the takeover and is now one of Nokia's largest remaining business units.
So that's my explanation of "bad". Oh, and to the gentleman who called me "lazy" and that I "don't like change"... how about making an app that's in the top ten list of paid music apps and requires 60 hour weeks... then you can talk to me.
Hear, hear. A lot of people on here don't understand the difficulties of software development and are very quick to insult developers.
If you only support iOS 7, you'll find that 100% of your user base can use the app.
Nokia had plenty of time to update the app for iOS 7. Its failure to do so is its own fault.
It did not receive a single update the whole year that it was on the app store... The only point for that app was just to poke fun at Apple Maps and nothing else...