UX Help welcome | SQRL Forums

UX Help welcome


Active member
May 19, 2018
Hi everyone

I've added some areas that I like help on GitHub but I feel that I have more urgent need of help with UX so I write here to.

Do we have anyone with UX work experience that understand the application or are willing to get it explained from me and can after that mock up a good UX design so users can use the application with ease.

I've started to create some screens at mockflow but if you prefer another tool that's fine too.

Best regards
Daniel... If we don't have enough such people here, and I suspect we don't... I can mention this on Tuesday's podcast and I'm SURE it will get a response.

The problem is, I'm not yet ready to tell the world about this place, just like you're not yet ready to have the world providing more feedback than you can handle.

So I will solicit help on Android UX design, and I'll filter the replies through the SQRL feedback page. That way we're not inviting 250,000 podcast listeners to come here (yet) to look around, and then I can tell only those who are sincerely interested to drop me a line on the SQRL feedback page and THEN I'll tell them to come here. Yes?
Hi Steve

Thank you, that sounds like a good approach. I'm a bit aware of scale but when we have 100k people or more enjoying the applications we need to work as a group so we all can help out and answer questions. That will become a full-time job for any one of us otherwise, I'm afraid.

Finding someone that could help us get UX as easy and intuitive to use as possible is one of the more important parts to gain adoption.

Thank you for your time.

Best regards
Daniel. My day-job is as an Analyst/SQA includes requirements, specs and testing for Windows and Web apps. So of course UI/UX are extremely important. I have also worked on an iOS app project and did some screen mockups / transitions for test planning and internal demos. I also have an old Android phone that I use to have an understanding of the OS and app differences vs iOS. While I have limited time, like I'm sure most people here, I'm happy to help in any way I can.
  • Like
Reactions: hackersarchangel
I have written some basic programs myself, specifically using AutoIT (back in the day) and more recently, Windows Forms via XAML. I am using your app at present on a Pixel 2 XL, if you have anything you want me to look at it/test, I'm up for it.
I do IT security work as a developer and many of my projects have consisted of internal Android applications for companies. I will throw my hat into the ring for helping with the UI/UX for this project if you would like my assistance. I have an array of phones and android versions we can test against. I have a couple points of feedback on some parts of the process we could clean up. How would you prefer to handle the UX feedback? I can submit issues against the github repo, a pull request if you want me to tackle some of the code, or I can create threads/posts in the forum for discussion.
Hi everyone

Great to hear. At the moment I feel that opinions are easy to find. But in order to do a cohesive experience we need to rework the UI taking the suggestion, opinions and criticism in to account.

So my thought was to collect all feedback in GitHub, forums and newsgroup. Then create some kind of visual representation that we can work out a good flow for the application.

At the moment all UI is ad-hoc. So I want wireframes or something that we then can implement. We have a few developers on GitHub already and more are welcome.

But at the moment I made a wireframe and that got implemented before I knew if it was a good idea.

I don't say that we can't iterate but inventing to many strings that people translate and then we deprecate them is not a good use of anyone's time :/

Looking forward to working with you all.

Best regards
Last edited:
Hi again.

Another thing I didn't mention is how I think about the application. This is a login tool. So I want to restrict it. It needs to be small, fast and feel like a native experience.

So using the Android best practices of UI design would be great. Using built in features and visuals are good. Using SVG instead of graphics.

If the download size gets to large people in regions where you pay for your traffic might not want to download. If we use none native UI we need extra libraries that either require more memory / download size. Or we restrict the device the application is available for.

At the moment I've set the minimum version to 18 because less than 1% of users have older versions and that is the oldest device I can test on. Then again if we want we can support older if we can reliably test it.

Best regards
Whoever designs the UI should probably know Android Material Design. This makes it much more straight-forward to implement and it squarely meets user expectations. There is the question of how closely it will match the iOS side, because Apple has their own standards (and Apple users have their own expectations). I've got an app released on both Google Play (Java) and the Apple Playstore (Swift), and I made them look pretty similar, but matching them exactly wasn't worth the time. Neither perfectly matches their mobile OS standards either o_O

I agree with Daniel that getting a complete UI design done before embarking on coding it is the best idea; doing it incrementally would involve more pain, IMO.
Another thing I didn't mention is how I think about the application. This is a login tool. So I want to restrict it. It needs to be small, fast and feel like a native experience.
Just wondering about the difference between making it streamlined and small versus making it friendly to new users. So as not to bury the lead, I'm thinking we need two versions of the app!

The version of the application for the new user would have a "wizard-like" on-boarding thing that would prompt and check and assure and answer questions along the way and leave nothing to chance. That interface would practically be an application in itself, and all it would have done is guide the user through creating an identity and priming the user for what to expect! I envision just a few words per page (most users don't read more than a few words at a time in an app, we're going to be dealing with millenials here, hehe!) My experience watching people use an app that I released is that they just start a clickin' like crazy...they don't read anything. Or if they do, it happens in about 1 second before they want to move on to another screen. The app should have diagrams, and simple graphical representations of what it "feels like" to operate in the SQRL "eco system" (not what it's doing under the covers). Of course this version of the app could scan/authenticate (with first-run assurances and diagrams and stuff too, that could be turned-off by the user). This version of the app would be bigger to download, but I don't imagine it would be any less responsive once the user had seen and clicked "don't show again" on the tutorials. I'd be inclined to forget about internationalization until the English version was running well, and was well accepted; Android makes it easy to do language after the fact since it points out every time you try to sneak a string in that isn't in strings.xml, hehe!
Hi @sengsational

Good points but I believe you can do a good onboarding experience without using 4MB pngs for every tutorial screen. I can even add a tutorial video for the play page so people that want to see the experience first hand can see it. (I create a video every week so one more would not be that much more work. :) )

Best regards
Hi All, I reached out to Steve after hearing his request for UX/UI help for the Android app. I'm a software engineer with a good background of Google-based development and some Android experience. My shop focuses on material guidelines and mobile-centric applications.

Is there anything I can do to help you all?
@pedigo, welcome! If you got familiar with the process to set-up an identity, that would be where I'd start. Then translate that into some kind of storyboard that could be used to make it really clear to a non-techy user what was going to happen, what was happening, and what just happened.

Although I've only gone through the identity creation process on Daniel's client, I plan to do the same on Steve's implementation. Jeff's iOS might not be available for me to experience since I don't have a physical iOS device and I'm not sure the *.app file can be made available for me to run on my simulator.
Hi all, I’ve found you from Steve’s announcement on SN. My name is Mark Roudebush and I’m a Senior User Experience/Product Designer with over a decade of experience designing for just about every type of interface platform you could imagine. I’ve spent time at some top design studios, startups and larger tech companies. My background started in visual design focusing on brand and information design. I’ve been thinking of contacting Steve lately to discuss my interest to merge UX and security and well here we go. I’m happy to take the project on and can spend some time reviewing any documentation you have to begin a phase of clarifying both the intent of the tech and the experience I obviously know, but in a more formal process. After that point I’ll want to identify user paths. Primary and secondary flows, “happy paths” as they are often called, cross platform instances... In short there are steps and tools to planning the experience which will happen before screens. I was happy to read “on-boarding” above. I believe this is going to be a critical touchpoint with users. We’re talking about a pretty significant mental model shift with end users. From what I understand Squirrel is a very easy process. We should be happy about this but also consider what that will mean to users who have been conditioned that good security is hard and painful.

If my approach and ability sound like a fit and you would like to partner, let me know and I’ll move forward soon with ramping up.
In there's a link to a diagram showing all existing functions of this app. The issue itself is about figuring out the primary use cases so that could guide the design. The context was that the app was just started, and the structure today is still mostly the same, but with some polishing to remove pain points.

@kalaspuffar what do you think is the best next step? Wireframes, copy-paste mockups, or more meta discussion to make sure everyone's on the same idea of how this "SQRL Login" app is used?
Hi @Simon9

I think you talk about this one.


Best regards
Hi @Mark_roudebush

I would love if you can take lead on this project. I see a lot of opinions in the forum and elsewhere about UX but I'm not skilled in this field in order to know the right approach.

The UX designers I've worked with before have done most of the work to figure out the correct flow of the application and depending on user feedback and other research they've created flows and designs that I've implemented.

I can make things work but I have not the experience to figure out the best flow for this application.

Earlier I got the feedback from an experienced designer that the main function should be front and center in the application. That's why I've created a simplified view with only one large button in the middle of the screen starting the main flow.

When you've set up your application you should just click the button, scan QR, type password and done.

Same goes for URL login. Click the button on the page, type password and done.

Other pages are scattered and mostly organized to minimize clicks and interactivity. But I might use the wrong words to guide people or the wrong structure so any guidance and work you can give to this project I would greatly appreciate it.

If you have any questions don't hesitate to ask and I'll answer as soon as possible.

Thank you for your time, looking forward to working together.

Best regards
Mark, I think the combination of your expertise and "fresh eyes" can yield great usability/understandably benefits. My recommendation would be to treat the fact that bad guys can't break-in as "the air"'s all around us, but we don't really notice it. Sum it up as "the power of cryptography" and assure the user that the system has been designed from the bottom-up so bad guys can't harm you. Then throw in the fact that in a decentralized system like this, there is more responsibility on the part of the user. But everywhere else, I think it would be wise to simplify interactions and terminology, ignoring underlying details unless there's a clear need for the user to understand something. So the fact that something is getting encrypted or decrypted isn't important for the user to know, for instance, because that's just part of the bottoms-up secure design.

Also, I see that there might be a "SQRL client lite" that might be an interesting place to start. The client would not have any identity creation / management functionality. When you first opened it, it would scan an identity. After that, it would scan login codes and accept master passwords and quick passwords to logon to web sites. No other functionality. If you scanned another identity (or the same identity a second time), it would simply confirm that you wanted to replace the single identity (because we limit this client to one identity). Settings > About would be the only other thing needed. The idea is that this client would be super simple on the face of it (but of course the full crypto implementation under the covers). The identity creation function would, of course, have to be be done not on the lite client, but on the user's "main SQRL client".

So if the UI for the lite version was defined, it could also make the full implementation clients more usable since all that other "stuff" could be buried deep. I was thinking that some of that stuff should require entering the master password, even though it's not required technically. There's LOTS of stuff that should NOT be easy to access! In fact most of the stuff on that diagram posted earlier should not be easy to access. The identity creation should certainly be easy to access on the full client, at least if the state of the machine is that it has zero identities. Once it has one identity, it should be buried deeper. Some activities, like changing master password and re-keying need to include a way to keep the user out of hot water because there are bunches of pitfalls if they have multiple clients. So support for the whole "synchronize clients" thing will probably consume quite a bit of "strings.xml".

If any of that doesn't make sense, I'm sure it will once you start playing with it yourself. Cool you're here.
Fantastic, I'm very much looking forward to this. I'll begin digesting what I find here on the forum and on your Github Daniel.
My first step is to get a grasp on understanding what you have and to do that I'm sure I'll pull together plenty of questions. Bear with me while we do this. We'll get to user flows, and designs soon enough. The more complete this initial work is the more efficient the actual screens will be. A few questions I do have now.
  • What is our timeline? Milestones?
  • Who is working on the web and iOS experience?
  • Who is on the core team? It looks like you are in Sweden Daniel? It would probably be good to do a call at some point when I get my head around some of this.
---- Is there stakeholder buy-in (Steve?) as we move forward with decisions?

Thanks again for the initial dump of info guys. I'm excited about working with you and bringing some excellence to the user experience of Sqrl.

As Daniel said earlier, SQRL is a login tool. On Github he lists as his first use case: select an identity, and login. All of the other use cases are administrative. I think all SQRL functions can be divided into three groups.
  1. Same device login - click sqrl link opens SQRL Auth page, Android SQRL allows ID selection
  2. Different device login - when using a PC without SQRL, launch app, tap logo to launch scanner, Scan QR on PC screen and enter pwd, user is authenticated on PC -- but currently no ID selection on Android auth screen
  3. Admin - some will be done once (per person - create id, rescue and pwd), some infrequently (Import to new device), and some (hopefully) never (alternate identity, rekey ID)

I believe strongly that many (if not most) will share devices with other family members. After the basic login function, the ability to do so easily with any identity on the device will be essential. Note, the Windows client, the Android and iOS clients all support multiple identities now, but only the Android app currently has the option on one of it's auth screens where it needs to be.
  • Like
Reactions: Mark_roudebush