I think it will do alot of good if a chronological order is followed with regards to which task should be worked on fast. I think Must /Easy, should be completed fast, then Must/Medium and finally Must/Hard. As this will ensure that the intern warm up the intern, making him/her prepared for harder issues, tasks sharing similar components should be worked on subsequently because there is a higher chance to move faster.
I have opened this for sharing information with mentors and interested interns and community members.
Basing on the fact that the scope is well defined and very clear, i think the entry-point should be changing the styling and the basic arrangement of of the Implementor tools, to display the toolbar on the top-left, create an arrow-down button to toggle implementor tools view, and change the general implementor tools to a dark background.
This will solve some of the marked Easy tasks in the project plan.
However, i think we should re-think about how we open the portal to display the implementor tools because i realised that elements rendered on top of the widget don’t register event listeners.
If i append a button as a child to this portal, it has to be clickable together with the underlying elements. Actually, this button is visible to the user but invisible to events like click, hoover, focus.
Could anyone have information why this is behaving as so?
I have explored different options of how we can bring the ui design for the new implementer tools to life and i think i am narrowing down to 2 options.
To keep the iframe intensive, we shall embrace useMemo hook preventing it from reloading on multiple rendering. We shall also need to give the iframe maximum width, height and position it relatively so that it appears on top of he currently displayed esm-app.
Displaying this might me hard, so we might just find means of preventing the currently displayed esm-app like when at home, esm-home and when at patient-chart, esm-patient-chart from rendering ideally, display: none
We shall need to prevent the implementer tools form appearing in the iframe otherwise we shall have a loop, breaking the UI. We can do this by like disabling implementer tools in the iframe, ie all element nodes with <div id="single-spa-application:@openmrs/esm-implementer-tools-app-page-*"
Approach
Either pass the current html node via the srcdoc property or the current current page via the src property like;
I have already used css to create the desktop view of the new implementer tools and I also think that the tablet view of this is can also be created. However, we shall need to position elements manually each time the implementer tools is open. We can setup a listener each time the implementer tools is open and apply some styling depending on the screen size so bring out either the desktop or the tablet view.
Since we can pass states from the window to the iframe, and at the same time it can manage its state, i think we can easily bring out both views properly with little tweaks.
I would personally prefer using Iframe but both approaches require some tweak.
Current Appearance
What approach should be best @vasharma05@bistenes@ibacher@dkigen@hadijah315?
I am also so open to better suggestions so as to bring out this with least complexity but with a good performance.
The iframe option would certainly be cleaner as long as it has the following characteristics:
The app state remains the same when the implementer tools are loading, other than necessary adjustments for screen size.
The user is still able to interact with the application with the implementer tools open.
When closing the implementer tools, the state of the application should not change other than resizing.
If we can meet those requirements, the iframe technique should work. That said, the real thing you should be pursuing is “whatever gets this feature working”… there are a lot of improvements we can and should make to the implementer tools.