Skip to content
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

Improve the editor UI for larger screen devices #1173

Open
Nirajn2311 opened this issue Jan 17, 2024 · 1 comment
Open

Improve the editor UI for larger screen devices #1173

Nirajn2311 opened this issue Jan 17, 2024 · 1 comment
Labels
status: discussing type: feature request Threads classified to be feature requests. Implementation to be considered as a nice to have

Comments

@Nirajn2311
Copy link
Member

Now that we have a couple of certifications in the mobile app, the editor UI can be improved to be more responsive. Here are some thoughts I had:

  • Currently when the user clicks on the editor with the instruction panel panel closes when the keyboard pops open. While this behaviour makes sense for mobile devices as the screen size is small and the user won't be able to see much of the editor. But in large screen devices or tablets, we can keep the instruction panel open or reduce the size of it when the keyboard is open.
  • We can also make UI a bit similar to the web by showing the panels side-by-side when the device is in landscape mode

If anyone has any more ideas, we can discuss it here.

@Nirajn2311 Nirajn2311 added type: feature request Threads classified to be feature requests. Implementation to be considered as a nice to have status: discussing labels Jan 17, 2024
@Nirajn2311 Nirajn2311 pinned this issue Mar 18, 2024
@paclarap
Copy link

paclarap commented Nov 13, 2024

I'm suffering as well from this.

With the editing restrictions (due to the used/builtin editor/highlighter which randomly steals selection/focus in the mobile app as well as in the web version) on iPad (in my case iPadOS 16.7.10 on iPad 12.9" 2015 1. Gen) it's a shame to not have the description pinned to the top in portrait-mode.

For one screen space is wasted.

Also since the selection of the description text is prohibited as well, in lessons where a lot of text is to be inserted into the code-sections, or for example long URL's it becomes so tedious to constantly switch between the description and the code-view, that it is almost impossible to keep motivated to go on in the app. Switching to the web-version becomes a must then but suffers from the same selection/copy-issues as before-mentioned, though totally randomly/irreproducible in contrast to the mobile app where it is blocked/not enabled.

On top the theming-issues which make it extremely hard to see the marked-as-code/marked-to-insert almost indifferent background-color ...

In short: Having this would relieve from lots of problems, that seem to be hard-tied to the embedded editor/syntax-highlighter/theming.

So two (simple) options for now to optimize the app in this case:

A) Pin the description so it stays readable on tablets.

and/or

B) Allow selections in the description view, so lines/texts/URL's so long that it is nearly impossible to memoize them temporarily can at least be copied.

P.s.: I am a friend of paper and pen, as it helps memoizing stuff, but for URL's and content/texts this is not a helpful workaround, but distracts even more from learning the actual coding/structure.

P.p.s.: While i have had a hard time setting the local-dev version up and still have no clue about flutter, i would love to get some pointers to where in the source the editor/highlighter mangles in, where i can find the layouts/behaviors for the descriptions and especially the theming. I dug through the sources many times, but without knowing the intricacies of the platform and what to look for its hard to find out what needs to be learned to be helpful to the project.

It would be amazing if there was a tablet-specific layout and especially to learn how to figure out the structure of the app. As of now for a newcomer it feels unreachable to grasp the data/control-flow.

Would be nice if you can share some thoughts on this.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: discussing type: feature request Threads classified to be feature requests. Implementation to be considered as a nice to have
Projects
None yet
Development

No branches or pull requests

2 participants