hi, it’d be better if we worked on our wiki, imo
It would be better to use OpenEMR’s wiki but the existing contents are pretty messed-up (sorry, in place of better word), too many broken links and outdated documents. Many time my search did not generate good results. In many areas the contents are mixed with current release and previous releases. That, in my opinion, may not not be a good strategy. Really confusing and hard to related to the installed version.
I suggest we create a new wiki and port over current contents. This time by each release and clear sections.
I just don’t see why we need another wiki to better organize. Other things to consider is that additional resources will cost more for hosting and will have to be supported as well. The wiki was recently upgraded to run the latest mediawiki, the software that runs wikipedia, and was placed on a new droplet running ubuntu 20 so it’s in good position to last awhile.
1 Like
So walk through this experiment. How would you organize this new wiki, what documentation would you add, how would you lay out the sections? If you’ve developed a plan of attack for how you would organize the wiki (if you were to start from scratch) then the next stage is to build a migration strategy of migrating any content you find relevant to the new sections/layouts. All that would be work you would have to do anyways if you were to start ‘a new wiki’. That same effort could be applied to the existing wiki.
There is over a decade of information in the old wiki. Quite a bit is out of date, but there is also a lot that is not. It would be a very heavy lift to just get rid of it all. The other thing to consider is that there are still a number of users that are on OpenEMR 4.2 and OpenEMR 5 release that still need and use the old documentation.
I know I have the same tendency to just go into the OpenEMR codebase and start chucking stuff out, but that’s a good way to break things that shouldn’t be broken. Its the downside of working on any large enterprise/‘legacy’ project of how to make changes without breaking the system. Its doable, but it does take effort. Often monumental refactors just blow up as there’s not enough time and resources for people to get it done before life pulls people away. Small incremental changes such as taking one section or one area you need / want done is more doable and will result in actual progress. Others will start to build on your work if you lay a foundation that they can build on. I’ve seen that happen with what I did with the module work, I would argue the same could be done for documentation.
Hi @adunsulag,
Agreed. The main strategy is fine. But the approach needs more refinement and control. Give me until this weekend and i will produce a template for review.
I my opinion, i wouldnt want to fool around with the existing wiki. As you rightly said it a spaghetti. Trying to make sense from that may end up into a life long task (hehehe… i know I may be over reacting). Proposing a sort of compromising solution to what we intend and what @stephenwaite said earlier.
My proposal is this:
(1) We continue existing wiki
(2) We create another fresh wiki (still under openemr community)
(3) Create a “GuideBook” for each release (lets start with version 6) with the template (to be agreed)
(4) Then pull each item from existing wiki, review and if still applicable repost in Guidebook under appropriate sections. Also the post should contain description, howto with screenshots and examples (see example below). This may be a lot of work but with a group volunteers we can do it.
hi @murugappan ,
I agree with items 1 and 3. See no reason to create another wiki, which will burden the community (resources to maintain/update wiki software) and cause confusion (if a primary argument is that the main wiki is causing confusion, then what will happen to confusion level when there are 2 wikis (with competing google search indexing))?
HI, @brady.miller
Thank you for the feedback. Its just a suggestion Both option have their pros and cons. Accepting your reasoning, the reason why i am suggesting another wiki is that people developing the new format contents may accidentally break the existing contents and links. Its ok to use existing wiki if this element of risk is acceptable.
Dropping this link here as we’ve previously had extensive discussion surrounding this topic.
Hi @robert.down ,
I read through the proposed strategy. I am inclined to say no to the recommendation to use Drupal (or for the matter, Joomla or WP). Mediawiki is fine and easy to use as a reader. As an author, learning is an additional activity curve but, i guess, the same goes for Drupal as well.
Using Drupal and a new Mediawiki instance is almost the same except porting from old to new would be much easier and quicker with a new Mediawiki. I am saying all this will a total lack of usage knowledge with Mediawiki, which is not good but its an attempt. “Never say die without a try” hehehe…
In any case, I am acceptable to contribute to whichever strategy adopted. Main thing is “lets do it”.
Hi Murugappan,
Abdul here from Infosty Technologies.
Thank you for this post - I was planning to do the same thing (Redesigning the UI/UX of OpenEMR). While going through this thread, the topic was changed from ‘how to redesign interface’ to ‘Documentation’ 
Please share if you have received answers for your questions about style sheets, and php scripts etc.
BR
Hi Kumara,
Have you redesigned the User Interface/forms design or using the default one?
BR
Abdul
Hi Rob,
Very good work - Thank you for sharing the strategy doc.
I and my team would be happy to contribute as much as we can, particularly in documentation and re-designing of the User Interface.
BR
Abdul
Hi BR,
No answers yet. I have not been working on the EMR project for sometime. Was busy customizing a CRM software and transforming it into a Document Management System. Works great now.
I am yet to install version 7. I wanted to start on the very sight of the notification but what put me off is the use of Docker. Seriously, i am not a fan of things like Docker, Gulp etc. Its just adding layer upon layer. Its like creating a megalith from a monolith. Another future strategy of moving the platform to Laravel frightens me more.
Will soon get back on, devoid of docker. Will post updates later. So sorry did not answer your Q satisfactorily.
There is work ongoing to move from Bootstrap 4 to Bootstrap 5 right now. Docker is here to stay for OpenEMR, but there is nothing stopping you from setting up a non-docker development or production environment. Unfortunately, build tools like Gulp are currently unavoidable as we use SCSS and that must be built to plain CSS. While one day I can see OpenEMR using primarily CSS Variables (thus reducing the SCSS uses) I imagine there is going to be at least some SCSS pre processing for the foreseeable future
1 Like