-
Notifications
You must be signed in to change notification settings - Fork 0
An user friendly account set up wizard with automatic settings detection mechanisms.
I will rework the account configuration of K9 into 3 main parts ( start with, see ‘notes’ ). These will form a wizard.
This first part will try to detect as many e-mail addresses on the devices as possible. It will list the results. It will also list an item named “other account” as first. This will be clicked when the account the user wishes to configure was not found. The activity has these options: “manual setup”, “skip”. The last one might be disabled if there are no accounts configured yet ( or not? depends on the desired behaviour ).
I see two sources for these accounts to be checked. The first is the android AccountManager class ( http://developer.android.com/reference/android/accounts/AccountManager.html ). This class will be scanned and e-mail addresses ( using a regex to determine ) will be listed as options. The second source has to be implemented but I think people are working on it: a previous configuration/backup of K-9 on the SD card.
When the user clicks a list item a dialogue asks for the password and we go to the next step.
We use the Thunderbird ‘waterfall’ to autoconfigure the mailbox. It’s described here in great detail under “Mechanisms”: https://developer.mozilla.org/en/Thunderbird/Autoconfiguration. The only one we won’t do ( for now ) is the one using a harddisk ( SD ) file.
This will be implemented as a progress bar with output underneath it. This will be ‘understandable’ by a regular user and has two benefits. First he doesn’t feel like he’s waiting very long because he knows what’s happening. Second it helps if something goes wrong to know what. The messages would look like “Connecting to ISP database”, “Querying the database for example.com”, “Trying to connect with gathered settings.”, “Guessing: trying mail.example.com.”,...
If successful we ask the user if he wants to configure more accounts yes/no. If he does we loop back to the ( slightly altered version “Choose another account to configure:” ) of the first screen. If not we go to the overview of the mailboxes.
If unsuccessful we go to the third screen which is the same as the “manual setup” screen.
This one is least innovating one. It’s just a form containing all settings to be able to connect. The only thing I would change ( for now ) on the existing solution are the errors ( I know the error handling is reworked as a whole for K-9 ). I would make them more “commanding”. Instead of ‘username/password are wrong’ the error would say ‘Try again using another password. Check the username’.
The first screen will still have a “pro option” as it does have now. So people will still be able to just enter all the data themselves quickly. I think this should always be possible ( in all applications in fact ). I think in time there will be another screen after part 2 when it was sucessful. This will contain some often used settings so the user can choose these as part of the wizard. Stuff like when to sync, if he wants the account to cause notifications, if implemented: wifi/3G,... There has to be decided which ones are ‘worthy’ of being in the wizard on this extra screen. It would have the options “finish/skip”, “add another account”.
I will implement this all in a series of separate and defined steps. At this moment they would look like this: Implement the backend for using the Thunderbird ISP database. Writing “helper” classes and some unit tests maybe? This part itself has subparts: the Thunderbird ‘waterfall’ system. Each layer is a part itself: using the isp db, checking for config files at the isp, smart guessing. Tying them up to part 2 of the proposal and the current view. So ‘enhancing’ the current view with these features. This would already result in something mergeable. Reworking the whole setup. First of all adding part 1. Account detection. Writing the backend for this ( detection ). Creating the view for this and connecting the two. Again this should yield a mergeable result. Finishing the wizard as a whole ….
These are just some thoughts:
Since K-9 is widely used it would be wonderful if we could use the settings entered by users to help others. After a successful manual configuration or a successful guess we should ask the user if he wants to help others by sharing ( and tell him this does not include his login/passw ). Ideally we should add it to the Mozilla ISP database but I think this isn’t possible yet. See: http://support.mozillamessaging.com/bg/kb/ISP+Database#How_are_ISP_database_records_added_and_how_are_they_validated_to_ensure_that_they_are_legitimate_ and http://ispdb.mozillamessaging.com/add/ . So I’ll have to look into it.
Another idea is sharing them with one contact. If I know a friend has the same isp and he uses K-9 I could ask him to share them ( through an sms or something ). He would then have this option in the new account management screen ( see part ii. of the next paragraph ). But this is just me writing down what pops up in my head :-)
If I would be finished before the end of the summer ( and I really think this is possible ) I see three paths to continue my work. Fixing bugs: I could just make my way through the issue tracker trying to fix as many bugs as I possibly can.
Begin work on a separate account management activity: I would love separate the account management functions and settings in a separate activity. I think this would make more sense then the current setup where it’s blended in one activity together with the folders ( ofc these two are related so it also makes sense ). I feel this split would contribute to the user friendliness of K-9. If the mentor would advise me to continue my work on this idea I would first write a small document about what the exact goals would be and how I would implement them. I’ll explain here ( very short ) what the result would be.
The current “accounts” view would lose the option “account settings” in the context-menu of each list item ( these equal accounts ). It would also be renamed “mailboxes” or something. The view would only serve as a “doorway” to the different accounts messages, the integrated inbox and listing all the messages. The current menu option “add account” would be renamed “manage accounts”. It would take the user to a separate account management listactivity where clicking an item would bring the user one level ‘deeper’ into the account specific settings for that account. The back button would take him one level back to the overview of all the accounts.
I feel this would provide a better overview for the users. When browsing through the issue tracker a lot of features are requested which are account specific: not storing a password for one account, only syncing an account on wifi/3G,... If they were to be added they’d go into the new account management activity so the account specific settings are grouped together and easily managed, looked up and compared. Start working on a consistent and well designed error-reporting system: This one is already on the sketchpad but I’d like to do this one too. I could start after the main project and continue after summer. I know what is expected and there is info on the wiki so I won’t discuss it here further.
Some ideas on where you expect problems or can see things being time-consuming
I don’t foresee any specific problems. I never written a big android application so I might have to read up a bit more then people already familiar with the sdk but I have not problem with that. I’m a quick learner ( cliché but I really am :) ) and used to learn stuff on my own. I have 2 courses this semester with no lectures only thick books. It’s far from the first time I have to use documentation and API’s to look stuff up. On top of that I already experimented with the android sdk a bit and read some tutorials so I know the basics.