Build a robust application structure

[sfount]

BHIMA is currently about 50% responsive, many components and screens break or tear on smaller sized screens and not many of the application pages are consistent with how to do layout.

As well as this the current overall application structure was a CSS prototype that worked and was kept around, elements like fixed header, nav and footer were then added on top.

I think it would be beneficial from a support/ reliability perspective to carefully architect the overall application structure to account for:

• Both small and large screens
• Easy to read and write syntax structure
• Flexible components that don't cause unexpected behaviors (currently if the programmer doesn't implement the header or the footer on an application page the page shrinks and is still offset by those non existent elements - from a developer perspective having elements that simply take up their space when they exist would be a much better guarantee when thinking about how to implement a certain page)

Unexpected design errors are usually easy to work around (position : absolute hack for example) but I have certainly underestimated the amount of development time they take every time something new has to be designed or added to the application.

This is a difficult decision as the software is currently being used and this would involve tweaking the UI. However I think the benefits gained from a reliable, easy to add to and evolve structure would far outweigh the cons. It's also worth noting that the longer this doesn't happen the more users we will have to migrate.

My proposal to cover the points I have described in the issue are:

• Design a side bar that has a fixed width - the % width causes it to become unusable on a medium sized screen
• Allow the side bar to have a compact icon view (for example 50px) that can be expanded to a full utility view (250px). This would allow partials to be rendered with much more space on a smaller screen whilst simultaneously not comprising the utility of the full sidebar view. (Unfortunately this is much easier to do from the left hand side of the screen which may involve a change)
• Create a flexible application structure that allows for an optional header, utility menu and footer, whilst always making space for a clean independently overflowed content area. All of this must be specified with the partial view. This content area also must respect the position of the side bar.

It would be really great to hear feedback on these thoughts - I understand that this will involve uprooting a lot of currently working design patterns (although hopefully no partial code will change) but I fear that if it is left any longer it will never get done. Please let me know if you think this should be addressed.

(If this issue does not describe anything clearly I could put together some mockups/ sketches to demonstrate the proposed change)

[jniles]

I'm heart and soul behind this change. You didn't say this explicitly but if this will happen at all it needs to be while bhima is still beta. (re: migrating more users to a new UI).

The benefits go even farther beyond what you mentioned. It would be very nice to have some more expressive and standard syntax for designing our HTML pages. I was particularly disturbed to see that on FireFox, Chrome, and Chromium (Linux) many of the pages (in particular, the reports/ pages) render three different ways! And that isn't even between different screen sizes! It's clear that we need to have more care when building and designing our pages, and a full on analysis + standardization as you are proposing would do that.

However, all that being said, I fear that we need to focus on cleaning up accounting before working on this. Dashboards aside, I cannot think of many more new features that we will be developing in the coming months. On a timeline, I would put this off towards December, focusing on making sure reports for Stock, Patients, Sales, and Cash flow are all pristine, we have a correct chart of accounts, our posting journal is feature complete, and the like.

@DedrickEnc , what do you think?

[DedrickEnc]

I don't see why we have to wait until December, once the team is completely in Kinshasa we can seat and walk objectively through the application. After this analyse, one of us can tackle this issue (it can take a week may be more). The most important question is : will we travel this month? and Tshikaji users must get all changes during this travel? This change, if integrated in BHIMA, it should be a major change, we will be supposed to change the BHIMA version. So I agree, we must create an issue for that (even if I don't completely understand it, the Steven's English becomes very tough for me), this issue will be tackle after the BHIMA global analyse (where we will talk about SNIS, BHIMA restructuring, Statistics, Stock, BHIMA vision for four nexts months ...).

[jniles]

It will take more than one of us to tackle this issue -- in fact, it will take the entire team. Everyone will have to understand how the CSS works and be comfortable using it. The initial prototyping can be worked out by @sfount, but we'll need everyone to start adopting a new standard of coding.

The questions of installation are a separate issue, and we should discuss them outside of this thread.

[DedrickEnc]

This task seems similar to the server side breaking out performed by @sfount many months ago. The server was changed by Steven only to avoid confusing and errors and then every one was supposed to adopt it. However getting all or a part of the team doing that issue is also good for me. I am not talking about installation @jniles, BHIMA is already installed, I am worry because this issue is essentially to make user experience greater and we should know when and how they can get them and avoid many trips for minors changes.

[sfount]

Thanks for the thorough comments @jniles @DedrickEnc.

@DedrickEnc You speak such excellent English I often forget it is not your first language. I will continue trying to write clearly.

I think it is mostly agreed that this is a necessary change, however I agree it would be beneficial to all be working on it together. It will be a very good thing for us to all review the application and make sure everyone knows how we can best use this time of crucial development. At this point of analysis I think we can decide to implement this issue, if done correctly it shouldn't require very much change from developers as long as they understand how to use the new structure.

Up until we have done this analysis I will begin researching how this could be done using best practices. Perhaps we will all agree on an early prototype and can integrate it sooner however I think it will be an iterative, collaborative change.

This discussion thread will be a good reference for planning the feature.