Things I would love to see in iOS 5(shorts.adityamukherjee.com)
shorts.adityamukherjee.com
Things I would love to see in iOS 5
http://shorts.adityamukherjee.com/post/1635264081
27 comments
My phone spends 80% of its time in landscape mode. Mail, Messages, Safari, Camera, Twitter and the half a dozen games I have are all better in landscape mode than portrait. If you see that list, 4 apps are by Apple itself. Not to mention any app that needs you to type is infinitely better in landscape mode. Only Calendar, Maps and Phone aren't there because Calendar doesn't have landscape mode, and Maps and Phone are better in portrait.
I wasn't trying to imply that Apple shouldn't redesign landscape mode home screen for the phone --- it was just an idle comment you make when you're thinking out loud. My point/request still holds. Having the option of a landscape mode home screen is much more useful than not. And that's precisely why there is a portrait mode lock available --- for people who don't want it.
I wasn't trying to imply that Apple shouldn't redesign landscape mode home screen for the phone --- it was just an idle comment you make when you're thinking out loud. My point/request still holds. Having the option of a landscape mode home screen is much more useful than not. And that's precisely why there is a portrait mode lock available --- for people who don't want it.
I agree that I would prefer they don't add in landscape home page. As it is, most people have developed a certain flipping technique for rotating their phone in their hand, which is much harder to do with an iPad. And once you introduce a landscape home screen, then you can't use spatial memory to launch apps anymore. Personally, I would prefer that the iPad used a 4 x 4 set of icons for just this reason. Icons are always in different positions and I need to search rather than know where they are using memory. In contrast, My finger is on the correct icon instantaneously on the iPhone.
If the icons rotated in place, the icon positioning might not be too bad.
While I see the use of changeable text in icons, like the calendar app employs, why would anyone want to have animated icons? Perhaps it would be an "eye candy" thing to show off with for 10 seconds, but I'm sure it would be annoying in the long run.
Any ideas for reasonable uses of animated icons?
Yes, Statsheet was denied putting 345 apps in the store for each college basketball team. If we are only allowed to have one app, then the user could choose which team is theirs, and then the front Icon would change to represent their team.
A static icon change would achieve the same thing. You don't need animated icons for that.
To OP of this thread: It was another idle comment. The crux of the request was in boldface.
To OP of this thread: It was another idle comment. The crux of the request was in boldface.
Changing the icon would make it significantly harder for me to scan and find what I'm trying to run. I worry that it'd be abused with a POTD concept or some such nonsense.
A tighter implementation would be a limited amount over overlay that was configurable -- like the alert # but with more control. The important point being that the underlying icon that I scan for still being available.
MacOS uses this in a number of places to identify download, symlinks and the like.
A tighter implementation would be a limited amount over overlay that was configurable -- like the alert # but with more control. The important point being that the underlying icon that I scan for still being available.
MacOS uses this in a number of places to identify download, symlinks and the like.
In other words, "make iOS more like Android".
Just shortcut the entire process, http://lifehacker.com/5693309/how-to-install-android-on-an-i...
Just shortcut the entire process, http://lifehacker.com/5693309/how-to-install-android-on-an-i...
"Dynamic Icons, API to fetch URLs in the background, Better Push Notifications, Wireless Sync" « none of these will happen unless Apple gets their hands on a much longer-lasting yet thinner and cheaper battery. Because unlike Android phones which comes with a removable battery and thus battery drain != a useless brick as long as a replacement battery is at hand, iOS design/feature-set has to be very careful about battery conservation given Apple's hardware design choices.
Having said that I fully expect, Apple, who has been in the business of making software for close to 35 years, which is a full 5 years more than "90% guy" Microsoft, already have these features either on their ToDo list or in prototype form just waiting/working for the battery tech to reach that threshold where they are confident of it holding up when used by the mass market.
In short, I don't expect iOS5 to have most or even all of these features but maybe by the time iOS6 rolls around, battery tech will have reached the point when these features would have become practical. For iOS5, the flagship feature( Steve calls them 'Tent-poles' )will be NFC, and joining this tent-pole on stage will be the usual hardware improvements, Game Center/Ping updates etc, but nothing of the sort that has the potential to 'leech away' the battery.
Having said that I fully expect, Apple, who has been in the business of making software for close to 35 years, which is a full 5 years more than "90% guy" Microsoft, already have these features either on their ToDo list or in prototype form just waiting/working for the battery tech to reach that threshold where they are confident of it holding up when used by the mass market.
In short, I don't expect iOS5 to have most or even all of these features but maybe by the time iOS6 rolls around, battery tech will have reached the point when these features would have become practical. For iOS5, the flagship feature( Steve calls them 'Tent-poles' )will be NFC, and joining this tent-pole on stage will be the usual hardware improvements, Game Center/Ping updates etc, but nothing of the sort that has the potential to 'leech away' the battery.
NFC = Near Field Communication, it is a short-range high frequency wireless communication technology which enables the exchange of data between devices over about a 10 centimeter (around 4 inches) distance.
From http://en.wikipedia.org/wiki/Near_Field_Communication
From http://en.wikipedia.org/wiki/Near_Field_Communication
- API to run some form of background task as needed
- Revamp notification, maybe notification centre
- API to change home screen icon.
- API for NFC as it is rumored to be in iPhone 5 hardware
- Spotlight API for app content searchable under spotlight
- AirPlay 2 - api to push screen to AppleTV and convert iphone/ipad as controller, make it easy to support this functionality in games
- API for social liking and following, Apple'own social networking build into iOS 5 and Lion
- Apple Messages/Chat, telco independent sms?
A big feature conspicuously absent from iOS is a unified documents folder accessible by all apps, and some basic file management capabilities. It would preferably be mounted as a virtual mass storage device when you plug in the USB cable. Here's hoping this'll be one of the features of 5.0.
I don't think you'll see any traditional filesystem exposed on iOS. Apple seems pretty determined about this. But I'm pretty sure we will see more support for sharing documents between applications, perhaps with MobileMe integration.
I think what you'll see is an extension of what's done in the calendar app in iOS 4. That is, the calendar database is a specialized database just for calendar, other apps can access and modify it, and it syncs with the cloud and all your devices.
I think you will see the same thing for many other types of databases, but they will all be dependent on type. The databases already there are music, contacts, notes, PDFs in iBook, epubs in iBooks. I think you'll see the full ability to access and modify those databases, and full cloud syncing of them as well. But, they will still be different and separated by file type or task.
I think you will see the same thing for many other types of databases, but they will all be dependent on type. The databases already there are music, contacts, notes, PDFs in iBook, epubs in iBooks. I think you'll see the full ability to access and modify those databases, and full cloud syncing of them as well. But, they will still be different and separated by file type or task.
A better feature would be to make documents created by apps searchable via spotlight. Files are bound to apps anyway, it shouldn't matter to users WHERE they're stored, as long as they can search for them (which is infinitely superior) and open them.
A unified documents folder just doesn't work as seen on OSX.
Most filetypes are bound to a specific application anyway, so there's no point in a cluttered unified folder.
Why would it be cluttered? It could work just like Settings.
Apps with their own document type register as such with the OS. The "Documents" app shows a list of those apps and each one leads to a list of documents for that app. From this list, users can open, rename, delete, attach to an email, and so on. Apps would not be allowed to dump internal junk in their document folder, only stuff the user creates and knows exactly what it is.
As long as this model was enforced by the OS and by app reviewers, it should be easy for anyone to understand. It would give iOS something fundamental that Android doesn't have at all, which it really needs because it's playing catch-up with most other features right now.
Apps with their own document type register as such with the OS. The "Documents" app shows a list of those apps and each one leads to a list of documents for that app. From this list, users can open, rename, delete, attach to an email, and so on. Apps would not be allowed to dump internal junk in their document folder, only stuff the user creates and knows exactly what it is.
As long as this model was enforced by the OS and by app reviewers, it should be easy for anyone to understand. It would give iOS something fundamental that Android doesn't have at all, which it really needs because it's playing catch-up with most other features right now.
If documents are categorised by apps, why have a separate browser for them instead of keeping them in the app? If I want to view my Pages documents, I'd open Pages not Documents or whatever it might be called.p
Lots of great reasons:
1. The user can manage all their stuff in one place with consistent functionality across all apps.
2. The OS can implement generic file handling features like search, share, backup, sync, etc.
3. It paves the way for standard file types that can be handled by multiple apps, or apps that can work with any type of file, like Dropbox.
The power of filesystems is well understood and I'm sure Apple could create one instilled with their magical UX and just-worksiness. But they won't do it because I think they are afraid of 3rd party apps becoming too useful. They don't want anyone else creating an ecosystem that they don't control. But Google and RIM are happy to do that and I hope they establish a higher standard of utility that Apple is forced to live up to.
1. The user can manage all their stuff in one place with consistent functionality across all apps.
2. The OS can implement generic file handling features like search, share, backup, sync, etc.
3. It paves the way for standard file types that can be handled by multiple apps, or apps that can work with any type of file, like Dropbox.
The power of filesystems is well understood and I'm sure Apple could create one instilled with their magical UX and just-worksiness. But they won't do it because I think they are afraid of 3rd party apps becoming too useful. They don't want anyone else creating an ecosystem that they don't control. But Google and RIM are happy to do that and I hope they establish a higher standard of utility that Apple is forced to live up to.
Many file types can be opened by several different applications, and using the Mail app to transfer them from one app to another as we do now is simply an awful, awful kludge. If I'm looking for a file on my iPhone, I'd much rather have a central document repository to look through than to have to dig through a bunch of emails to find the attachment in question, or use a bunch of unique app interfaces with their own document management implementation. This limitation is so obvious that I'm surprised anyone would actually think the status quo is acceptable, let alone advantageous.
"Better Push Notifications: Apple should just straight out copy Android’s Cloud-to-Device API. That’s it."
Or, you could try my app, Jumping URL (http://www.jumpingurl.com), instead.
Or, you could try my app, Jumping URL (http://www.jumpingurl.com), instead.
hey buddy, i like your thing but umm your app won't download in the app store. it says that it is no longer available.
> API to fetch URLs in the background
Oh yes please, that would get rid of the overly complicated workaround of using PUSH-Notifications for that.
Oh yes please, that would get rid of the overly complicated workaround of using PUSH-Notifications for that.
New API to handle calls inside an app and access call data such as history.
Furthermore, the iPhone is primarily a portrait device. The iPad, not fitting easily in one hand, is as much a landscape device as it is a portrait one. I'd be surprised if Apple "enabled" a landscape home screen for iPhone in iOS 5.