-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Misc: Mobile UI #181
Comments
I'd vote for a responsive UI using a flex-grid or similar. I do not back my frontend skills enough to take this on though. |
I support one responsive UI. The main issue when designing for smaller mobiles (i.e. iPhones, such as the SE, in portrait mode) is that the space is very limited. As I see it, there are four main* elements to the CyberChef page, defined as:
Cramming the 4 main elements into one screen is difficult. The commonsense solution would seem to be to separate them out into pairs of two - however, recipe theoretically needs to be seen with both operations and with output (for making a recipe and then stepping through it purposes). Therefore, I would propose a design with a fixed bar at the top showing options and support, a fixed bar on the bottom showing download and latest release, and then a 4-row stacked column, stacked in the following order: Operations Recipe Output Input I'm not an amazingly talented developer, but I'm competent, I'm willing, and I've got free time. If y'all can think of any conflicts, I'd be glad to hear what you think of the proposed design. I'll send up a visual template of the design I'm proposing this weekend. No guarantees on speed with this, but seeing as the issue has been untouched for ~2 years, I don't foresee that being a problem. |
@Cal-Hagner I'd maybe change the order of |
Notes:
Notice: As I begin to work from my fork of CyberChef, I may need some assistance with figuring out how to view my edits in my fork in the GitHub page at https://cal-hagner.github.io/CyberChef. I'm familiar with front-end, it's just GitHub I don't understand. 🙃 Happy holidays! |
bump |
…ptions [FEATURE] Allow for status checks to non-HTTPS content Fixed gchq#181
Heya CC, I've been working a little on this and so far I've landed on the following mobile UI layout: A few choices I made and why:
Please do share your thoughts! |
…appropriate places when the UI is solid )
… an if statement checking the breakpoint
…ly revert some things once the mobile UI is solid, then patch up desktop view to its original state
…t more space for mobile usability
to complete the cut off commit message above: "add 'add favourite' capability for mobile UI |
…ically scale based on #controls height, which makes adjustWidth() redundant. Controls is now 50px height on mobile ( 70 was just a lot of wasted space that can be better spend )
…rflows under any situation
…anner. No need for the controls at this point while scrolling the ops
…et op description errors
… Nighwatch to be able to run
…ors when not available
…'favourite' class on init as well
…the ops-lists in Operations every time a new operation is added or removed, only rerender favCat and handle the updating of the individual operations 'favourite' classes and icons
…o be re-rendered ( such as Favourites, but can be used for any Category in the future if needed ), additional refactoring to make previously mentioned functionality work
… ), fix popover issues ( popovers properly disappear ), eslint cleanup fixes
…e searchbox border nicely
… 40), as per the current width implementations on init
Summary
The current UI isn't very good on mobile devices. We should start thinking about how we can improve it.
Possible solutions
There are two paths we could go down:
I'm keen to hear people's opinions on which route they think is best. There are definitely pros and cons to each one. If we create an entirely new UI, it will break a lot of the code in
src/web/
which is currently tightly coupled to the existing DOM. However, modifying the current UI to work better on mobile could result in messy code if it isn't done well. This could be a good time to start buildingindex.html
in a more modular fashion so that the code becomes easier to maintain.If anyone wants to mock up some designs for what a mobile UI could look like, please go ahead. The focus should be on simplicity.
The text was updated successfully, but these errors were encountered: