Open SecUpwN opened 9 years ago
Since you brought this up, I have been thinking to make some simple descriptive changes for a long time. Surely these can be improved upon with more and clearer eye candy, but the descriptive text is still essential for the non-informed user.
Here I show the current menu versus the changes.
---------------------------------------
MENU (current layout)
---------------------------------------
Tracking:
Start/Stop Monitoring Cell Details
Start/Stop Tracking Cell Details
MAIN:
Device Details
Cell Information
AT Command Injector
Database Viewer
Map Viewer
SETTINGS:
Preferences
Backup Database
Restore Database
Application:
Get OpenCellID Data
Lookup Current Cell Details
About AIMSICD
Quit
---------------------------------------
MENU (preferred layout)
---------------------------------------
MAIN:
Cell Information ==> Current Threat Level --> AIMSICD stat, neighboring cells, ciphering method indicator
Device Details ==> Phone/SIM Details --> SIM network provider details, IMEI, TMSI?
Lookup Current Cell Details ==> All Current Cell Details (ACD) --> Show detailed comparison of the currently connected cell,
with the data (if any) found in OCID AND highlight the differences.
Database Viewer --> This take you to view the different DB tables we have.
Antenna Map View --> A map showing color coded antennas of nearby cells
AT Command Interface --> AT Command Processor Interface that allow sending AT commands to BP
Tracking:
Start/Stop Monitoring Cell Details ==> Toggle AIMSICD monitoring --> This Start/Stop AIMSICD from monitoring and collecting cell details into internal database tables (DBi)
Start/Stop Tracking Cell Details ==> Toggle 2G-only network lock --> Start = Set phone to use 2G mode only, for tracking. Stop = Use default Network Type (RAT) settings or Automatic?
SETTINGS:
Preferences --> AIMSICD settings and preferecnces such as polling times and service bahaviour etc.
Backup DataBase --> Backup AIMSICD SQLite3 DB to SD-card
Restore DataBase --> Restore AIMSICD SQLite3 DB from SD-card
Reset DataBase --> Clear and reset all or specified DB table(s)
Export DataBase to CSV files --> Export DB tables into individual CSV files
Import DataBase from CSV file(s) --> Import DB table(s) from individual CSV file(s)
Application:
Download Local OCID Data --> Downloads OCID Data for the current country or region (determied by Network MCC ?)
Add/Get OCID API key --> Get an API key for using the Open Cell ID database to upload and download data... **FIX
About AIMSICD --> Who we are and who we support
Help/FAQ -->
Quit -->
Here the symbols ==>
means rename to this, and -->
the descriptive text that should pop-up when user click on the :information_source: icon.
Then there should be some internal-to-app help pages and I suggest the following style for simplicity:
=======================================================================
AIMSICD Application Help Pages
=======================================================================
The HELP menu system has 3 types of help "pages". You can swipe left
and right to move between them, or click on the corresponding item
on the "tool-bar".
| General | Short | Dictionary | FAQ |
[1] 'General Help' about AIMSICD's functionality
[2] 'Short HELP' for each application item
[3] 'Dictionary' of Mobile Network Terms
[4] 'FAQ' to answer many common questions.
@E3V3A, I will take care of the renaming after releasing v0.1.25-alpha-b9
. Or should we wait until we have found an awesome layout and everyone agreed on the new redesign of the whole menu?
Well, the renaming anyone can do after b9
but there is some technicality of the Current Threat Level
items, which is now using the multiclientril thingy, and need to have the ONE detection icon. In addition this should probably be the first "page" the user see when opening the app (apart for the disclaimer/GPS stuff). So that one is probably experimental at first...
So let's take things a few steps at the time.
@E3V3A, did you finish all the necessary text string changes, or do I need to pick it up somewhere?
Generally speaking, we need to be discussing how our App should generally look and work in the future, I think our whole team (calling @tobykurien, @evilsocket, @He3556, @Ueland and also @andr3jx) should have a close and thorough look at @wasabeef's Awesome Android UI/UX Libraries, vote for their favourite and discuss how to further proceed in the transition. Because if we keep changing stuff without having the goal in front of our eyes, we might be walting the wrong way. Let's just find out where we want to go before we move in different directions. I know this is a difficult task, but we better solve it now. :trollface:
It would really rock if some professional UI/UX designers like @starflower, @skienzl and @xamoom-bruno would participate in this discussion and give some hints on a better design. IF we are going to improve the UI/UX to make our App have a unique look and feel, I really want it to be some design that is flexible but looks and feels awesome at the same time - means, that we can stick with it and do not have to rethink our App design every time there are new items. Thank you very much, folks!
Are there any existing design documents that we could start with? The interface seems like it might be quite daunting to the target audience (for example, users already have to know that your cell phone communicates with towers, and the transmissions can be intercepted).
I would like to take some time to work on + implement some UI/UX changes, but the goal of the application isn't clear to me. As a quick sketch of use cases/personas:
I appreciate any feedback you might have on this, even negative feedback like "this is dumb"/"this is overengineered". Thanks!
Hello @wttrtpy - welcome and thanks for your ideas and help.
First i need to say something about EVA's post. Did you forget the "Debug View"? i really don't want to use a extra APP just to see what our App is doing. i really hope you forgot it and you are not planing on deleting it. I also read comments about our App (Google-Code and other Blogs). And i can say people wish to know, what exactly the App does in the Background. We can not tell the people "you don't know anyway so just forget it". The people that are using our App right now, are mostly technicians who want to see all details.
@wttrtpy - sorry, but there is nothing like design documents we could hand you out. So i will just go on and add my thoughts about this.
1. I think we should start with the colors, fonts, buttons and representation of tables and cards.
#222
- but not black)#ffea59
We should keep the Icons that are in already, like they are. But we could add some icons because this is what modern design looks like nowadays. Icons. In general i like the design of Bootstrap. If we use this we had some basic design that looks great.
2. We can have a look at the awesome links SecUpwN postet earlier in this Issue. There are some concepts we could use. ExpandableTextView is one i would like to see on the "Database Viewer". This would help to make this view clearer and we don't have to scroll for ever before we find something. With the "Expand all" button we can still see it like it is now.
3. (maybe for another Issue - but i want to mention it here - if i have to implement it by myself it will take some time before it is finished.) I want a widget for our App. Besides the Threat Icons i want to show a log that shows what the app does in a way we see it in "Debug View". Minus all the logs that are not important for detection. Log can be switched on/off but all positive detections will be shown to the user. Maybe we can use some small icons that are blinking when there is a certain action. Like when the "Changing LAC" routine is used, a small led blinks on the widget. So we (and our users) can be sure it runs in the background.
We definitely need some feedback for the user and i vote for a widget.
Well if nobody else of our team is answering... @wttrtpy you wrote: (for example, users already have to know that your cell phone communicates with towers, and the transmissions can be intercepted). He wouldn't even search for the App, if he doesn't know that. The usage of the App is quite simple, just open it, get the OCID Key and download the db.
But maybe you are right and we should make this clearer. ... actually i must say you are totally right! We got a little blind for these simple things :)
If there is a positive detection the status icon changes and we are thinking about a alarm sound that can be played. (that was about your point 1 - 3)
About No4: We don't contribute data to OpenStreetMaps. But if the user wants he can contribute his cell tower data to OpenCellID. See "Preferences"
The No5 i don't understand - we are talking about user cases, right? So the APP can not only be used by technical geeks. I hope i could answer some of your questions
Good evening, everyone! How awesome to see some discussion in here. Thanks for your eagerness to help us on the redesign, @wttrtpy! You've stated a great sum-up of all our app users.
Debugging
shall not be erased since it is important for easy log collectionfor example, users already have to know that your cell phone communicates with towers, and the transmissions can be intercepted
Of course, because why should any user find our App then, @wttrtpy? How to make this "better"?
The No5 i don't understand - we are talking about user cases, right? So the APP can not only be used by technical geeks.
Just like @He3556 stated above: Our App shall not be just for "security freaks", but also for the average chump who has heard about StingRay and GSM Interception for the first time. We want our App to be easy to navigate and to understand so that is both fun to use but also very functional in design. We know that this is a hard task to tackle, but also an important one to make the general public more aware of the whole problem with broken GSM and lawful interception. Ok, enough for now, awaiting your feedback on these points. Please have a look at the links for UI/UX I mentioned here, especially on point 8.
ok @SecUpwN - no.1 - no.4 sounds perfect!
so it looks like we have a plan here :)
no.5 let us take the Proxima Nova and Museo Slab 500 (but isn't a free font)
I have a link were both are freely downloadable. Not sure if that is legal though. Avoid this?
i think Bootstrap is a lightweight framework = better performance.
Yep, good reference. Add the Material Design Icons to that and a little awesome navigation = perfect!
so it looks like we have a plan here :)
@wttrtpy, do you have any other questions? Feel free to craft some mockups prior to coding it.
After some internal talk about the (positive) criticism of @wttrtpy :)
Great job guys! I'm all in. Just don't let this issue take over the detection functionality.
I started with a Style Guide (Corporate Design) ...from the discussion above.
I used the main page to show how it looks like.
Questions:
ToDo:
Thank you very much, @He3556! Please continue the Style Guide as necessary.
Thank's @SecUpwN for the page "Style guide" - i just saw i uploaded the same picture twice.
Our Style Guide has been updated. @wttrtpy are you still on it? Please delete your old fork.
@larsgrefer, I would like you to take a minute in the upcoming days to fully read this Issue and tell us your thoughts on the best app design that makes our app fast and pretty self-explaining to navigate while also adding uniqueness. Tossing in Material Drawer, not sure if this may be helping in the process to find a much better app design. In its current version, I guess it is pretty complicated for new users to find out what to do before using our app. After a new and fresh design has been found, we also need to have another look at #181. Thanks for reading the whole thing here and sharing your knowledge with us!
My (new) ideas about the design are:
I think the best solution is to use the official support libraries instead of third-party ones whereever possible
I think the best solution is to use the official support libraries instead of third-party ones whereever possible
Thanks for letting me know, @larsgrefer. Do you know any good designers who might help us with this?
Hi, I like the idea that each function can be accessed from the navigation drawer. However there is some issues with it, I think.
For making navigation more simple I would, throw out the main screen-s 3 way swiping feature. I would change every screen to a fragment, or every screen to an activity. The settings, about, debugging, I think should go to the action-bars dropdown menu. Some commands, that is useful everywhere like the Toggle Attack Detection, and Toggle Cell Tracking, should be Buttons on the action bar too. Like this:
I am really against close/quit/exit buttons in android. Its against system design. We can make good visual feedback of telling the user, that we shut down all services. Like Orbots huge onion button.
On first sight I think these changes would help a lot in the UX. Please tell your opinion about it.
@tt3mm I totally agree with you :+1:
For making navigation more simple I would, throw out the main screen-s 3 way swiping feature. I would change every screen to a fragment, or every screen to an activity. The settings, about, debugging, I think should go to the action-bars dropdown menu. Some commands, that is useful everywhere like the Toggle Attack Detection, and Toggle Cell Tracking, should be Buttons on the action bar too.
Awesome to see you back here, @tt3mm! Your proposed changes make sense, I totally agree as well.
We can make good visual feedback of telling the user, that we shut down all services. Like Orbots huge onion button.
Ha, I love that one, too! :)
On first sight I think these changes would help a lot in the UX. Please tell your opinion about it.
Absolutely! I'm sure that I am speaking in the name of our whole team here: We're thankful for every small pull request from you to craft the proposed changes, making our UI/UX more easy to understand and moving towards a hassle-free and unique user experience. Maybe you'll even find time to re-read this whole Issue and see if you can give our app a touch of glamour, make it a bit unique and outstanding while at the same time following the design standards to ensure it can be expanded in functionality later?
@CellularPrivacy/design, please take the minute to read Design for Open Source by @dperrera. It exactly describes our situation. Thanks to @thechangelog for posting this in their latest newsletter!
FWIW, #898 contains docs with some Stingray details.
Resulting from our internal discussions to make our App become more user friendly and add some unique look and feel to it, I am opening this Issue to collect Ideas and launch a public discussion for it.
This will and shall not be an Issue that we close within a day, but this should be thought through and discussed properly, so that in the end we have a unique App design that not only feels and looks great, but is also extremely practical out on the streets while hunting IMSI-Catschers. Once we have a final draft on how our new redesign shall be, I guess it's just a matter of how many people engage in coding it.
NOTE: We do not have to redesign the whole App here. But then again, it is a possibility, too.
General thoughts on how our App should be after solving this:
Maybe we can solve the other open UI/UX Issues as well, especially #190?Some great resources for inspiration:
Note: This Issue will be expanded upon further internal discussion, hold back the rant yet.
UPDATE 1: We now have a Style Guide which I will expand and update with stuff from our decisions.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.