Bank account creation workflow

Macorin

What's the design principle behind the workflow on the creation of a new bank account? Is the thinking to just leave the default title, "Bank Account" and then fill in the bank name? I have a bunch of bank accounts and doing that would give me a bunch of titles with the same name. I usually rename the title something like "Chase Savings" or "Personal Checking." If that's more the norm, why not just start us in a blank (ready to be named) title field?

The title field (all fields for that matter, not just some) would benefit from having the "x" button to delete all text in the field at the right of the field.

hawkmoth

@Macorin -

I usually rename the title something like "Chase Savings" or "Personal Checking."

That's exactly what I do, and not just in Bank records. I do the same for several Login records for my collection of Google accounts.

If that's more the norm, why not just start us in a blank (ready to be named) title field?

I don't know the answer to that, but I do know that if you are recording login when creating a new record from within 1Password itself, the application has no way to know in advance what the name should be. I suppose it could be blank, but I've never been bothered by highlighting the deulat name and then typing in the name I want. If 1Password offers to save a new login while you are on a web site, it does create a name from the URL you are visiting. I normally need to edit those too.

Macorin

@hawkmoth,

You touched on a key point. The only category I don't mind being pre-filled is logins. I usually change the name of that title as well. Even though the app has no idea what you'd want to name it, leaving it open to type a name would be fine by me. I guess they could always create a setting to allow it to behave by supplying an empty title field (to be named) or by filling with a form of the URL (what it seems to currently do).

That's for logins and logins have a special, almost separate status in 1Password. The app it seems was initially designed to keep track of login information. Since then, it has tried to become more of a full purpose data vault. In every other case (aside from logins) the title field can't possibly be filled by something remotely relevant (such as a form of the URL). Seeing that you, I and I'm guessing many other people rename the unnecessary default title, why not just leave it open and start the cursor there for editing on new entry creation? This goes for any category (aside from logins, but I'd take it on logins also). There's no reason why creating a new bank account should put "Bank Account", new secure note, "Secure Note", etc. why create the extra unnecessary steps for the user when it's avoidable? This actually pertains to any custom field as well. Why do new "Text" fields start with the word "Text" in the title for example? You have to then tap into that field, backspace (no "x" button), and type wha you need. You then have to go through this process over and over again for every custom field in every new entry. Then the capitalization is off compared to the defaults. The default titles start capitalized, but backspacing leaves you uncapitalized. I know you can hit the caps key, but again, extra steps.

I guess this post has to do with the lack of consistency in data entry and the unnecessary steps needed to get the job done. It just doesn't make sense.

Another issue is not allowing the masking of private data. I know you can choose the password type for any custom field, and I do, but this doesn't pertain to the bank accounts type, where the pre-created fields don't use the password type for account or routing numbers. Those fields are then open to prying eyes unless you ignore the pre-created fields and create your own. This simply isn't efficient use of time.

Just seems some more strategic thinking needs to be given to these areas of the app. I'd prefer to not have to use the password type for masked data. I'd rather have the option to mask any field I want by choosing a mask switch.

Thanks for reading such a long post if you've made it this far.

hawkmoth

I read it all, and I am certain someone from AgileBits will too and take note of your preferences on the matter. (I'm a fellow user who volunteers sometimes to help other users.)

Macorin

Gotcha. Maybe I'm in the minority on the topics I brought up. I know that people have different workflow needs and methodology. My favorite apps are those that allow the user flexibility in the workflow process. 1Password is still a great and highly useful app. I just think it could be worlds better on the editing and workflow front.

Have a great night.

Ben

We're always looking for ways in which we can improve. :) Thanks for your continued feedback on the subject, @Macorin.

Ben

Macorin

Hi Ben,

I just wanted to chime in again on some of the inconsistencies I'm experiencing in the workflow of creating and editing entries. I'm seeing deviations in the way 1Password for iOS handles data based on things like starting points and origins of creation.

For instance when you create a new login the title section is formatted to capitalize the first letter of every word. However, if you edit a login title, that formatting disappears completely leaving you with zero capitalization.

Point 2: create a secure note from the secure notes section and the title is pre-filled with "Secure Note." Both words are capitalized, yet backspace to erase it and you start with zero capitalization formatting. The second oddity is that if you were to creates secure note from the main screen, it doesn't pre-fill the title at all, but starts you with a blank title field. The formatting is still without caps.

Sticking with point #2, the same holds true for the other categories. Creating a new credit card entry differs when you start from within the credit cards section versus when you choose credit card from the main screen after tapping the "+" button.

These caps, no caps, title, no title inconsistencies run rampant throughout the app. In the end, you are left with a database with differing looks to titles and fields unless you go out of your way to make them consistent. This takes an enormous and unnecessary amount of effort.

To me, it really doesn't matter which way it gets formatted so long as it's consistent.

Keeping in step, you see the same inconsistencies when creating custom fields. Create a text field and the title populated with the word "Text" with the t capitalized. Backspace to delete the word and the formatting is set with zero capitalization.

It seems to me that very little thought and/or effort went into this area of the app. While the app is phenomenal, the workflow and inconsistency of data is abominable IMHO.

I also notice great discrepancy in the way the cursor jumps from field to field. Sometimes it is smooth and I see where it goes and the field is presented to me on the screen. Other times, it jumps to some unseen location and I need to scroll up and down to find it. Sometimes it jumps to where I'd expect and other times it doesn't jump at all when I'd expect.

I'm also noticing an oddity with secure notes where if I create one and add a custom field and no notes in the notes section, the title entry is skewed up when viewing it in the list of secure notes. It's as if it thinks there is text in the notes field. If you edit the entry, go to the notes section and backspace, the note title centers down into the center of the field title when viewing in the list of titles.

It's all of these little visual inconsistencies and quirks that take away from the pleasure of using this app. I really hope they can address these in the future.

Thanks.

cohix

@Macorin Wow! You've gone above and beyond with that testing, kudos :chuffed: I've read through every point you just made and it's very clear to me now that consistency in the editing workflow is something we need to work on. Some of the things here are visual glitches that we should be handling in the first place, and others are functionality specifics that we can absolutely go over with a fine-toothed comb. I'm going to bring these points in front of my fellow iOS developers and we will take a look at making some of these issues better.

Thank you again for the testing, it's posts like these that keep us accountable to a high standard, and we appreciate the occasional kick in the right direction :+1:

Cheers!

ref: OPI-3388

Macorin

Thanks cohix,

Happy to be the proverbial thorn in your side.

Ben

On behalf of cohix you're very welcome. We always appreciate the feedback. :)

Ben