Improved Bookmarklet

nargalzius

<div class="IPBDescription">A suggestion for an improved bookmarklet</div>First, I don't know whether to be disappointed that my suggestion seems to have disappeared after me posting it on every "change" of the support forum.



1. I first posted it in the blog entry that showed a very inefficient way of accessing multiple clipboard items - but I can't find that entry now

2. I then posted it as a legitimate suggestion before the support forum suddenly switched to a different engine.

3. Now that the forum is in ANOTHER (hopefully final) engine, obviously the old one is gone yet again.



So I'm posting it now, and I would really appreciate feedback from the developers if this is doable or not. Because really, on the one hand, I think it really solves a lot of issues with regards to the bookmarklet, on the other of course I'm not that good of a programmer to know the limitations.



This suggestion aims to solve the following issues of the current bookmarklet functionality:



1. Will only require to sync a js bookmarklet ONCE to an iOS device - and be updated forever more.

2. Since bookmarklets are essentially javascript any decent alternative browser on the iOS device (atomic, etc.) should be able to use it as well.

3. Will only take one round trip to 1password and back, but with minimal copy/paste procedures.

4. In addition to #3 it will be able to fill in multiple required fields instead of copy/pasting one by one.



Sounds like the magic bullet right? It very well may be if the developers take the time to look at it and actually try checking out if it's doable.



So here's the idea:



1. have a GENERIC container bookmarklet. Basically launching it will have:

1a. A text input field

1b. 2-3 buttons: lookup & submit & paste (optional)

1c. checkbox to auto-submit



2. User visits a site which requires a password.

3. User launches bookmarklet and clicks on lookup - which then redirects to 1password (if there's a possiblity to pass a domain value during the switch and have 1password display immediately the domains related to that value it would be even better)

4. User selects the entry they want, and the 1password app will have a "generate string" button - this generates an [encrypted] string that has all useful values (e.g. field names, field values, etc.) and copies to the clipboard.

5. User switches back to their browser of choice (iOS with multitasking should make this a piece of cake)

6. User launches the SAME generic bookmarklet again - but this time enters the string on the imput field.

7. User presses "submit" (and optionally check the auto-submit) to start filling in the fields.

8. Upon pressing "submit", the bookmarklet [decrypts and] "parses" said string contents of the input field and populates the fields (and auto submits if said option is checked)



So basically, the bookmarklet is some sort of universal container/parser which can be used in any JS capable iOS web-browser.

Given the way the CURRENT bookmarklet works, I cannot see why this behavior is not possible (apart from the encryption suggestions) - but then again, the OLDER way of multiple copy/paste practically copies to clipboard in plaintext so I don't think that's an issue.



So here we have a bookmarklet that has to be synced ONCE - and doesn't have to be updated - because the data is still ultimately taken from the app itself (which thanks to dropbox sync etc. can be updated on the fly)



And we also have the option to encrypt the string (like say generate the bookmarklet string with a hash specific to your particular password - and that can serve as the decryption key specific to your device. And again, it will work on ANY browser that has JS compatibility.



That last bit is over my head I admit, which is why I want a proper dialog to know if this is in fact feasible or not, and even if the whole encryption part isn't possible, the other aspects I'm sure are doable given that the current incarnation of the bookmarklet already practically does the same thing - only that it's self contained (data and all) - all we're doing now is relegating the "data" part to the application, but the leave the "automation" part on the bookmarklet (as it can already do)



I really want a discourse as to what is feasible or not in this approach instead of the usual canned "we'll look into it" responses I often get - because if it really isn't possible, then I will stop following it up, but if it IS possible, of course I want to really push for it since as I said, it solves a lot of issues.



The reason why I'm reviving this thought despite it "dying" without any notice is because I've seen some requests to support OTHER iOS browsers - and the suggestions usually entail creating support SPECIFICALLY to said browser.



My suggestion makes everything more compatible in the long run: by abstracting the data layer to the application, and implementing the "automation" layer in a form that ALL browsers can run (i.e. javascript) we should be able to do a generic bookmarklet that works with the SAME data (from the app) and apply it the SAME way accross DIFFERENT browsers that support the SAME language (javascript)

khad

Wow! Thanks for taking the time to write that up, nargalzius! <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Some interesting ideas. I am sorry they have previously gotten lost in some of the shuffle.



We are always working on new ways to simplify using 1Password on iOS (and Android!) mobile devices, and we will take what you suggest into consideration! Just to recap for folks who are not already aware:



[list]



[*]Our current "[url="http://help.agile.ws/___?javascript:window.location='onepassword://'+window.location"]Look Up in 1Password[/url]" bookmarklet requires installation only once.

[*]It can be installed in any "alternative browser" (which I still find hard to write considering the only HTML rendering engine on the iPhone is WebKit not matter how it is dressed up <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />).

[*]When invoked, it will look up the specific site your are browsing in 1Password (using the JavaScript [font="Courier New"]window.location[/font] function).

[*]You can then simply tap to copy your password and return to the site and paste it in. (If you cannot remember your username when switching back to the browser, you may have to make an additional trip switching back to 1Password. This has only become easier with multi-tasking in iOS 4. A quick double-press of the Home button and a tap on the icon in the bottom left corner.)

[*] Of course, you are always free to use the browser built-in to 1Password for iOS which integrates more directly with the websites you visit.



[/list]



I hope that helps. Please let me know.



Thanks!

nargalzius

[quote name='khad' timestamp='1287169436' post='13363']

we will take what you suggest into consideration!



Our current "[url="http://help.agile.ws/___?javascript:window.location='onepassword://'+window.location"]Look Up in 1Password[/url]" bookmarklet requires installation only once.

[/quote]



I believe this feature is the same written [url="http://blog.agile.ws/search/copy+paste"]here[/url] right?



That's exactly the reason I'm pushing for this newer implementation, because that one isn't as "efficient" - especially the part when you have to deal with MULTIPLE fields: going to a "temporary" page, pasting there, then selecting, copying, switching, pasting, going back, etc. Is hardly an elegant solution.



The reason I'm pushing for this new one is since you already IMPLEMENTED that "not so elegant" solution - so I cannot see why this would not be a more welcome approach - and again, I'm willing to discuss this with anyone directly involved with development.



Again, not meaning to offend, but the response you gave I consider to be a "canned" one (we'll look into it - with no guarantee that it will be done) - I'd prefer a clear "yes" or a clear "no."



While I do not claim to be a ninja with programming, but given that there is already a current implementation that is [clearly] inferior in concept - what I would like to know beyond any doubt is if programmers can find a reason not to replace it with the one I suggested.



I'm totally fine with them saying "what you want cannot be done because of X, Y, Z, etc." I really won't be offended if they say it wouldn't be possible - but I really want the developers (not customer support) to be the one to say it with legitimate reasons as to why they arrived at the decision.



Feasibility is the ONLY reason I can think of why it would not replace the current implementation - I've been thinking long and hard and cannot imagine ANY other reason why my implementation, in concept, would be less ideal to what is currently available.



The thing is, given what the old and new implementations could do, I really think it COULD be done... and it's THIS fact I want to confirm with the developers. I don't mind waiting as well if it's low priority - but it would be nice to know if there IS something to wait for, or not.

nargalzius

I'm going to write a blog entry about it, just so I can just copy/paste in case it disappears again <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> But here's a more detailed explanation of my whole position:



Here's how the "legacy" bookmarklet looks:

[img]http://farm4.static.flickr.com/3163/2714591843_56e401d5b3_o.gif[/img]



From the picture, you can glean a couple of facts:



1. That it's possible for a bookmarklet to have logic that can detect domains.

2. That it's possible to use ecrypted data, and decrypt it with a key/password. If you would look at the bookmarklet string, it's essentially a self-contained encrypted string that stores contains [b]all[/b] login details - from field names to field values, to passwords, to domains, etc.

3. That it's possible for a bookmarklet to have logic that can both [i]detect[/i] and [i]fill[/i] [b]multiple[/b] fields automatically based on the data above.



This is actually already a pretty good implementation (and the one I still use over the "new" implementation, which I will discuss in a while) with only [b]one[/b] real practical weakness; if you update your database, you'll have to update the actual bookmarklet as a whole (since it's self-contained) and re-sync... that and you're limited to Safari (for syncing, i mean).



Given that we now have alternate browsers for iOS, it would be nice to be able to use the bookmarklet with them as well. I personally prefer using Atomic - if it wasn't for the fact that the bookmaklet syncs to Safari [b]only.[/b]



Then Agile rolled decided to phase it out (but is still avialable to those who want to use it) and replace it with [url=http://blog.agile.ws/search/copy+paste]this[/url] approach.



Now, what important fact(s) have we confirmed from the video?



1. That the bookmarklet can detect domains.

2. You can launch 1Password Touch (1PWT) from a bookmarklet.

3. Not only can it launch 1PWT, but it can have it automatically go to specific [domain-related?] entries on launch - suggesting that the launch command can accept arguments/parameters.

4. These parameters need not be hardcoded in the bookmarklet - since we see only one bookmarklet to handle all calls (duh!)



The new approach is pretty darn close as far as "the best that could be done" given the limitations of iOS. And for the most part, it is similar to what I had in mind, with two glaring differences:



Once you're dealing with multiple fields, the experience quickly turns to a [b]tedious and annoying[/b] one. Imagine having to go back to the browser in a TEMPORARY page to paste the multiple-values you need. Then switching back and forth to and from that page in order to copy/paste the needed values [b]manually!?[/b] [i]Ugh![/i] This is exactly the reason why a lot of users still like using the "legacy" bookmarklet over this new official one.



Another is that the "automatic switchback" from 1PWT assumes you're using Safari. So exiting 1PW will almost certainly launch that temporary page in Safari



[b][size="5"]The Solution[/size][/b]



So before I go into it, let's recap the current bookmarklet (the one in the video) by counting the steps needed to fill in a username/password field combination after landing on a page you want to log into. Items in [b]bold[/b] are steps that will be eliminated with my proposed solution. The item in [i]italics[/i] will be "modified" a bit.



1. Click on "bookmarklet" and switch to 1Password

2. Enter unlock code to access data

3. Tap on the entry you want to use (and type in master password if required)

4. [i]Tap on the icon to enable multi-copy to clipboard[/i]

5. [b]Select fields you want to include[/b]

6. [b]Tap "done" to copy to clipboard and switch back to Safari[/b]

7. [b]Paste values to newly generated [i]temporary[/i] page[/b]

8. [b]Select username by manually adjusting the selection tool[/b]

9. [b]Cut/copy username[/b]

10. [b]Switch to originating page[/b]

11. [b]Select username field[/b]

12. [b]Paste username from clipboard[/b]

13. [b]Switch back to temporary page[/b]

14. [b]Select password by manually adjusting the selection tool[/b]

15. [b]Cut/copy password[/b]

10. [b]Switch back to originating page[/b]

11. [b]Select password field[/b]

12. [b]Paste password from clipboard[/b]

13. [b]Switch back to temporary page and close it[/b]

14. Click on submit button to login.



So that's 14 steps give or take and starting from #8, you have to admit is VERY TEDIOUS. Now let's see how my implementation would do it. My proposed solution uses the truths already established from the TWO bookmarklet implementations so it's not like I'm pulling out a marxian solution out of my ass. The scenario I'm going to describe is all based on reasonable assumptions.



[b][size="4"]The New Bookmarklet[/size][/b]



Instead of a link to 1 password, the new bookmarklet will essentially be a "parsing" engine that can automatically detect and populate fields automatically. (again, this is possible because that's basically what the legacy bookmarklet does - less the "parsing" aspect)



So what it'll more or less have are these elements:



1. A text-input field

2. A "lookup in 1password button" (same trigger as seen in the current bookmarklet)

3. A submit button

4. A checkbox for auto-submit.



On the 1PWT touch app itself, the button that triggers the multi-item copy will be replaced with a button that copies a parsable ((Encrypted is optional)) string that contains all useful information about the site's form (in serial format perhaps?). We're talking multiple field names and values in one string which can be parsed later via the bookmarklet.



Here's how a typical session is going to go. Items in [b]bold[/b] are added steps. Items in [i]italics[/i] are the modified steps.



1. [b]Click on my proposed "bookmarklet" to bring up the popup dialog similar to the legacy bookmarklet.[/b]

2. Click on lookup button to switch to 1Password

3. Enter unlock code to access data

4. Tap on the entry you want to use (and type in master password if required)

5. Tap on the "new button" I described above to copy [b]all[/b] relevant data to the clipboard

6. [i]Switch to originating browser (Notice now it's manually done now - preferably via iOS multitasking) ((This is to allow users to switch to the actual browser they're using.))[/i]

7. [b]The originating browser technically should have the bookmarklet still up - now paste the contents of the clipboard to the input field.[/b]

8. [i]Click on submit button to automatically populate multiple fields based on the data parsed from the input field. Auto submit if "auto-submit" is checked.[/i]



If it is possible to have a JS function to get the contents from the clipboard automatically, then there's even a possibility that we don't even need a text input field to begin with and just have the submit button run the function that parses the clipboard contents from memory.



That's practically [b]half[/b] the steps, and it only required no fiddling with select handles, etc. almost all pure buttons (and worst case, you only have to paste [b]once[/b])



I challenge anyone to tell me how is this approach [b]not[/b] better than what they currently have. I do not claim to be a programming ninja, but quite honestly, I cannot think of any legitimate reason as to why they shouldn't pursue this method to replace the one they have now save for time constraints, or simply not wanting to do it.



Granted, it's infinitely more complex to actually program, but it can be done based on the facts proven above. But once off the ground, for the end user it's simpler, it works, it doesn't force a switch back to Safari, etc.



It's a win-win. All I ask is for a real developer in Agile take a look at it and evaluate it.

khad

Hi nargalzius,



Thanks for continuing the discussion!



If [url="http://blog.agile.ws/post/450859127/how-to-use-the-multi-item-clipboard-feature-in-1password"]this video[/url] is what you meant to link in your previous post (which only linked to search results), that feature is no longer present in the 1Password iOS apps. I do not believe it was ever present in 1Password for iPad.



So the current steps for the "Look Up in 1Password" bookmarklet on the iPhone are:



[list=1]

[*]Select the "Look Up in 1Password" bookmarklet which loads 1Password

[*]Type in your unlock code and/or master password in 1Password (if it is not already unlocked based on Settings > Security > Auto-Lock timeout)

[*]Copy password

[*]Switch back to whichever browser you were using

[*]Paste password



[*][i]Switch back to 1Password[/i]

[*][i]Copy username[/i]

[*][i]Switch back to whichever browser you were using[/i]

[*][i]Paste username[/i]

[/list]

Again, the username may not require a switch back to 1Password since I already know my username most of the time and can type it in faster than switching back and copying & pasting it. Those are the steps I have put in italics above. If I am just looking up my password, there are but five steps. We know this is not ideal, and, as I said before, we are always working on ways to improve password filling, but I will reiterate that we do not normally discuss upcoming features or release dates. We are a small company with limited resources, and any number of things can change between the time we would make an announcement and when or even [b]if[/b] a feature is included.



As you suggest, a method of improving the [i]app[/i] that would automatically copy both fields' information and an improved [i]bookmarklet[/i] that would accept this information to fill in [i]both[/i] fields would be very nice even if it only saves a few steps.



One of the reasons we are pushing the current bookmarklet is because of security. The older "1Password Logins" bookmarklet is a one-way sync from 1Password to your device. You cannot edit your information in the "1Password Logins" bookmarklet on your device like you can your logins stored in 1Password. We have always recommend using the "1Password Logins" bookmarklet for low-priority or low-security Logins. The warning displayed when creating a "1Password Logins" bookmkarlet in 1Password for Mac:

[quote]IMPORTANT: The bookmarklet data cannot be protected when used on a malicious web site. It is recommended that you limit its use to non-critical web logins. Use the native 1Password application for iPhone/iPod touch for the greatest security. It is available for purchase in the iTunes App Store.[/quote]

A hybrid of the two current bookmarklets that 1Password allows you to use would still require manually switching back to your browser and manually pasting the "token" into the bookmarklet since there is not currently a way to automatically populate JavaScript bookmarklets from third-party apps in iOS due to security restrictions.



It's a great idea, but again, we try to not make development promises regarding upcoming features or timelines, so my "canned" response is the literal truth. I promise I am no robot. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />



Cheers!

khad

By the way, I [i]have[/i] filed this as a feature request on your behalf. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

nargalzius

[quote]I do not believe it was ever present in 1Password for iPad.[/quote]



Maybe even more reason to revamp. Because I'm using the OLD bookmarklet on the iPad and it's working fine. I would imagine implementing my suggestion would also work since it retains the "execution" elements of the old, but the "data" element of the new.



Thanks for pointing out the updated method, however it's a bit misleading. Particularly here:



[quote]

Again, the username may not require a switch back to 1Password since I already know my username most of the time and can type it in faster than switching back and copying & pasting it

[/quote]



Even if you can type fast, the fact is you'll still be manually typing stuff. The longer your username (or if you use an email login), then it still becomes tedious. So please include the counting of taps for the actual username - as that's still done manually <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> Then imagine say, an email login (username@domain.com) - can you honestly say it's "faster" to tap in a username no matter how fast compared to automatically filling all fields with the click of a button - like how the old one did (and how my suggested one will as well)?



And that's only assuming you're using TWO fields. the method I had suggested also solves that since it can handle fields/values regardless of the number - just like how 1password desktop can auto-fill in forms in general - and just like how the old bookmarklet can do it automatically without any manual "typing" of ANYTHING (save the access code - which is not applicable now since we're taking a trip to 1PWT at least once).



So while unlikely, but say you required a 3rd (or 4th or 5th, etc.) field to fill up (for whatever reason) it can handle it automatically as it would be able to just search all the fields and populate it with the assigned values from the clipboard - all the relevant data would/should be there to parse.



[quote]

As you suggest, a method of improving the [i]app[/i] that would automatically copy both fields' information and an improved [i]bookmarklet[/i] that would accept this information to fill in [i]both[/i] fields would be very nice even if it only saves a few steps.

[/quote]



Exactly my point <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> ANd as I mentioned above, that's not a few steps saved. Unless your username is 1 character, then it will save exactly the amount of taps it takes to manually type in the characters of other fields apart from the password.



[quote]

One of the reasons we are pushing the current bookmarklet is because of security. The older "1Password Logins" bookmarklet is a one-way sync from 1Password to your device. You cannot edit your information in the "1Password Logins" bookmarklet on your device like you can your logins stored in 1Password. We have always recommend using the "1Password Logins" bookmarklet for low-priority or low-security Logins. The warning displayed when creating a "1Password Logins" bookmkarlet in 1Password for Mac:

[/quote]



Again, this is exactly why I suggested what I suggested. Yes the "data" is relegated to the application and not the bookmarklet. The new bookmarklet I'm suggesting still retains that abstraction (of the new one), only that it can handle MORE field/values - but they'll STILL ultimately be taken from 1PWT and not be "self-contained" in the bookmarklet.



Again, the reason I still use the old one is NOT because I disagree with the decision to switch to the current one's process - but because it's not as tedious - Which is exactly why the solution I proposed is technically more similar to the current implementation instead of the old one - but it addresses the tediousness aspect of it as much as possible (which the current one obviously does not given the "improvements" I've pointed out).



[quote]

A hybrid of the two current bookmarklets that 1Password allows you to use would still require manually switching back to your browser and manually pasting the "token" into the bookmarklet since there is not currently a way to automatically populate JavaScript bookmarklets from third-party apps in iOS due to security restrictions.

[/quote]



The new bookmarklet is just a parser/container, it has no data hardcoded in it. It just has the "engine" that makes it possible to detect and fill in values to MULTIPLE fields. The "token" would contain all the relevant data (in serial format, or character delimited, whatever) - not just ONE password, or not just ONE username - it would contain ALL field names and field values relevant to the "form" you're trying to fill (in this case, a login form). Then the bookmarklet engine will be able to parse and make sense out of the different field names/values and properly inject them to the form via JS (which CAN be done as the old bookmarklet proves)



Also, I'd like to clarify this line "there is not currently a way to automatically populate JavaScript bookmarklets from third-party apps in iOS due to security restrictions."



Again, the bookmarklet will just be a generic parser container... the data/token it'll use will be from the clipboard, not embedded updated in the bookmarklet at any point.



The fact that you can detect and fill in ONE field means the javascript is able to search for an html element (DOM) and fill it up. Again, this scenario I'm suggesting isn't something I just pulled out of my ass, I know it's possible because it has already been done (with the old one). And since the bookmarklet is JS, unless the "other" 3rd party browsers use a stripped down JS engine, I don't see why it won't work.



[quote]

It's a great idea, but again, we try to not make development promises regarding upcoming features or timelines, so my "canned" response is the literal truth. I promise I am no robot. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

[/quote]



I understand <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> And I guess it would be unreasonable to require such a promise. But how about this, can I at least get some kind of confirmation that the actual programmers of the bookmarklet have looked at this post? That's really the only thing I want to know. Perhaps they could post here and say "I've read this post, and we'll look into it" (since they'd be in this post anyways, it would make sense they'd actually READ the contents while they're at it even if they don't feel like it hahaha)



Again, the reason I suggest this confirmation is I really thought long and hard about this, and I feel it's a legitimate and significant improvement (which is why I challenged anyone to state reasons why they think otherwise) it really is a win-win if you analyze how the whole thing would work.



My frustration isn't really that it's not being done, but that I have no idea if you saying "we'll look into it" really means that the people concerned actually will take the time to do so. Never had that assurance even during the time my entries have been disappearing.

[Deleted User]

[quote name='nargalzius' timestamp='1287273952' post='13414']

I understand <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> And I guess it would be unreasonable to require such a promise. But how about this, can I at least get some kind of confirmation that the actual programmers of the bookmarklet have looked at this post? That's really the only thing I want to know. Perhaps they could post here and say "I've read this post, and we'll look into it" (since they'd be in this post anyways, it would make sense they'd actually READ the contents while they're at it even if they don't feel like it hahaha)



Again, the reason I suggest this confirmation is I really thought long and hard about this, and I feel it's a legitimate and significant improvement (which is why I challenged anyone to state reasons why they think otherwise) it really is a win-win if you analyze how the whole thing would work.



My frustration isn't really that it's not being done, but that I have no idea if you saying "we'll look into it" really means that the people concerned actually will take the time to do so. Never had that assurance even during the time my entries have been disappearing.

[/quote]



While I can't promise that our developers will post a response here, although both Dave & Roustem are very active in the forums, Khad has posted this to our internal issue tracker for 1Password for iOS, and all our developers review these issues on a very regular basis, and in fact so do a lot of the support team and we'll often discuss things around our virtual water cooler.



For the record, I love this idea, if we can implement something in this area with all the limitations of iOS development I think it'll make a great addition to 1Password. Ideally, of course, we'd love to improve 1Password's built in browser too, to effectively make it another browser within the app that could be used like Atomic or Safari and have full login saving / filling support as well as many other features.



Thanks again for the feedback,

nargalzius

EDIT: I composed this before STU replied. I would just like to make clear that I'm not angry or anything, I just sincerely think 1PWT can be improved and would love to see it become more useful than it clearly already is <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />



Also, I just have to point out that I'm quite uneasy with the "impression" that my suggestion might not be worth it because it JUST saves on a few steps. When I hear the argument saying "hey, you can still manually type you user name fast anyways, so it's not so bad. I can't help but think that it's more of a cop-out than a legitimate rebuttal against my solution.



While I don't take it personally (of course), but I just have to ask the question: What's the purpose of 1PW? Isn't it PRECISELY to make filling forms easier? ANd if so, how can a company have the stance of preferring to do stuff manually if there's a way to do it automatically (regardless of the "time saved")



If it really is such a compelling argument to just stick to manually filling some fields when there is a more efficient automated alternative that's clearly presented, then why bother with creating the app? Saying you can just "manually fill in your username," to me, is no different from saying just manually fill in your password for people who have "simple" passwords. What if your password is complex? What if your username is very long? The nature of the application is to alleviate these things, so I don't think the arguments of preferring manual input are acceptable in any way, shape, or form UNLESS there's no other choice (and in this case, there IS another choice) don't you agree?



While I do understand that iOS HAS limitations, I don't think my suggestion hits any of those limitations. Or if it does, it will still be more "functional" than the current implementation. (of course this may be debatable, but again, that's up for the developers to decide... which is why I want them to take a look at it and evaluate it)

khad

Exactly why I posted this earlier:



[quote name='khad' timestamp='1287263337' post='13403']

By the way, I [i]have[/i] filed this as a feature request on your behalf. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_wink.png' class='bbc_emoticon' alt=';-)' />

[/quote]





<img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_bigsmile.png' class='bbc_emoticon' alt=':-D' />

[Deleted User]

[quote name='nargalzius' timestamp='1287275481' post='13417']

Also, I just have to point out that I'm quite uneasy with the "impression" that my suggestion might not be worth it because it JUST saves on a few steps. When I hear the argument saying "hey, you can still manually type you user name fast anyways, so it's not so bad. I can't help but think that it's more of a cop-out than a legitimate rebuttal against my solution.[/quote]



We take every suggestion seriously, and honestly appreciate the thought that goes into a lot of the ideas, like yours. I don't think either myself or Khad are saying that your solution wouldn't be worth it, it would certainly be an improvement on the current solution, but that doesn't mean it will get implemented. The fact is that, believe it or not, we're a fairly small team and as such we do have to realistically prioritise the focus of our development.



[quote]While I don't take it personally (of course), but I just have to ask the question: What's the purpose of 1PW? Isn't it PRECISELY to make filling forms easier?



I mean if it really is such a compelling argument to just stick to manually filling some fields when there is a more efficient automated alternative that's clearly presented, then why was 1PW created in the first place?



I was under the impression that the nature of the application was to make it as easy as possible for people to fill in forms. Which the desktop does.[/quote]



1Password is indeed all about making it easier for you to keep track of your secure information, and as much as possible help fill this into web forms. As you mentioned the desktop versions can do this alot more efficiently than our iOS applications, for the simple reason that we've got direct browser integration without the need for bookmarklets.



[quote]While I do understand that iOS HAS limitations, I don't think my suggestion hits any of those limitations. Or if it does, it will still be more "functional" than the current implementation. (of course this may be debatable, but again, that's up for the developers to decide... which is why I want them to take a look at it and evaluate it)

[/quote]



I honestly don't know if your idea is possible, I'm only beginning to learn iOS / Mac development myself in my spare time, so the developers will certainly have to take this into account. I can't promise much more than we've already done though, and that's not to fob you off, but instead to say that we've posted it to the issue tracker and I'm sure they'll read the details there and evaluate if it's possible and at what stage we could look at implementing this.

nargalzius

[quote name='stu' timestamp='1287275212' post='13416']

1Password's built in browser too, to effectively make it another browser within the app that could be used like Atomic or Safari and have full login saving / filling support as well as many other features.

[/quote]



That would be nice, but honestly, I'd prioritize the bookmarklet because of their portability.



What you're assuming is that you can set 1PW as the default browser - which would be great if iOS allowed it.



But here's how I see it.



If I browse, sure I can use 1PW or Atomic when i'm coming from the dashboard. But if I'm reading from an RSS reader or any other application - and it has any feature that entails switching to the browser - chances are it will invoke Safari.



So even if you make PW THE pefect browser, for as long as you cannot invoke it natively from other applications, its features become useless. Unless of course we do the REALLY roundabout way of having an application "view in safari" then in safari have a bookmarklet that does a "view in 1Password touch" hahahah. That would certainly be an option - but as far as "ease of use" goes - the concept of a js bookmarklet is closest we have to a magic bullet - so I'd rather they focus on that (but what do I know, I'm just a regular user)



The bookmarklet approach is better in that sense because EVEN if you're redirected to safari, the bookmarklet is available in Safari, and it's pure JS which CAN natively invoke 1PWT. And because it's JS, that means it CAN work on other browsers that have JS support. Simply put, regarldess of the browser you choose to use (or iOS forces you to land in) "1PW functionality" will be avialable via the bookmarklet.



The "abstraction" is better because you have a single engine to "support" (the bookmarklet) that works anywhere universally (at least that's the idea if it's done purely by JS) then all the data/updates are still done to the main application.

nargalzius

[quote name='stu' timestamp='1287276106' post='13421']

I honestly don't know if your idea is possible, I'm only beginning to learn iOS / Mac development myself in my spare time, so the developers will certainly have to take this into account. I can't promise much more than we've already done though, and that's not to fob you off, but instead to say that we've posted it to the issue tracker and I'm sure they'll read the details there and evaluate if it's possible and at what stage we could look at implementing this.

[/quote]



Check out the 4th post. The assumptions I've made are based on the two implementations of the bookmarklet. And mind you, the legacy one DOES work to this day even with the newest iOS. I'll try importing it to Atomic though just to confirm if it also can work on ANY js-supporting browser (which would make sense)



But all in all, it HAS been done. The difference is that with my suggested implementation is that the "data" is not hardcoded anymore to the bookmarklet - instead, it'll be parsed on the fly (via input text field or clipboard) AFTER you take a SINGLE trip to 1PWT.



So it's literally a hybrid of the two "official" implementations - which BOTH work to this day.

khad

That's exactly as I described it on our internal tracker. I am rooting for this, too (unless there is already a better way under secret development). I never meant to come across as blowing you off. I hope you didn't take that away from my posts.



Seriously, though. We at Agile all "[url="http://en.wikipedia.org/wiki/Eating_your_own_dog_food"]eat our own dog food[/url]" which is to say that we are users the same as (if not more than) everyone else. We use our apps hundreds of times each day. Anything that makes the process easier for one of us, makes it easier for all of us.



We're all in this together. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

nargalzius

That's good to hear <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' /> Cheers!