Sales:-
Transactions
Sales Quotation Entry
Sales Order Entry
Direct Delivery
Direct Invoice

Maintenance
Add and Manage Customers
Customer Branches

Purchases:-
Transactions
Purchase Order Entry
Direct GRN
Direct Supplier Invoice

Maintenance
Suppliers

Items & Inventory:-
Maintenance
Items

Setup:-
Preferences

Scale down to 300px ish add some item rows in either sales or purchases and see what happens

username: demo
Password: password

Comments and feedback welcome

If this PR were included it would then be possible to have say a Bootstrap 4 renderer and a Material renderer be available as plugins (and then perhaps incorporated in the core once proven) and a whole set of Bootstrap and / or Material themes could then be very easily created.

@campbell Yes you do need js sometimes, the examples you've given could be retained. The point I was making is that, rather than add complexity to the js and therefore the core, surely it is better to get additional UI features etc from css leaving the core untouched.

Currently if you change a report or the report header files you put the modified file in the relevant company/x/reporting folder and this is used instead of the core version; this leaves the core untouched.

Probably not the 1st to have had the idea, but is it possible to use the same method for the ui files?

js would still be required for components, like the date picker for example or tabs.

It would be interesting to hear what the FA devs think about such things.  As you say there's not been much interest in supporting FA on mobile / tablets.

I completely agree that FA needs a html framework.
Does that framework need to be bootstrap? IMHO No, its bloated and relies on js; and from what I've read on here (or not read) has little support from the devs.

Perhaps FA devs would be more willing to change to a purely css framework? No js.

There is so much you can do just in css now, js use is decreasing as css functionality increases. Even css has its own grid system now!

One thing attracted me as a developer to FrontAccounting was the way in which the page views used ui functions to do all (well almost all) their rendering of html.  Because of this, all that is required to change the markup for every view is the 4 (or so) ui files.  To take advantage of current html markup frameworks, like Bootstrap or Material, the html does need to change.  Supporting multiple markup systems is easy, it just needs different implementations of the 4 (or so) ui files.  With a small amount of refactoring multiple markup systems can be supported at the same time.  This is polymorphism using classes, a very ordinary object oriented programming concept.

The modifications really are quite minor, the new ui classes diff very well against the existing ui functions.  Names are the same, parameters are the same so it is quite easy to keep the classes up to date.  I recently brought the code up to date with 2.4.3 and Bootstrap 4.

If that PR were to make it in to the core it then make it possible to safely experiment with new markup for new frameworks without breaking anything. e.g. Support for Bootstrap 4 could be introduced while still having Bootstrap 3 be the default, and so on.

There are two other ways that themes can introduce themes based on modern markup frameworks like Bootstrap.

1. Change the HTML on the fly with Javascript.  Change tags, add classes, remove classes and have a theme that works with the modified html.

2. Change the markup framework so it works specifically with FA's existing markup.  I've seen this done by some FA themes.  This is a lot of work essentially duplicating the work that went into creating Bootstrap (but easier - its based from it).  This is difficult to do well I think, its also difficult to incorporate new features from the ui framework.

I'm available to help (at no cost) should the developers want to incorporate this feature.

Swiftkey for Android auto injects emoicons based on context which will not be suitable for FA.

A mobile/responsive theme is available in some forks which have morphed FA considerably making it difficult to keep updating it when the core changes.

Creating additional user roles can be documented in the wiki with intent and purpose explained.

@joe: The viewport can be added if it does not violate strict browser settings.

File: access\login.php

62:   echo "<meta name='viewport' content='width=device-width, height=device-height, initial-scale=1.0'> \n";

And also in:-

File: includes\page\header.inc

145:  echo "<meta name='viewport' content='width=device-width, height=device-height, initial-scale=1.0'> \n";

@joe @itronics @apmuhu
As you probably know this will not make any changes to viewing FrontAccounting on a PC or laptop so you may want to include it in the core? It is also good practice to have a ‘viewport’ defined.

It only works if you hold you phone horizontally

Additional setup and changes to increase usability for mobiles

Create an additional user & user role, restrict access to menu items that you will need when travelling such as:-

Sales Invoices
Purchase Invoices
Add customer
Add supplier
Items
Reports

Hide unused menu items in config.php

Copy and paste a theme – rename for example mobileonly:- Some small changes to the css can make a big difference such as:-

Increasing font size and line height for menu items
Decreasing widths of dropdown menus, input boxes, date boxes, text boxes, etc.

Use a ‘split keyboard' such as ‘SwiftKey Keyboard’ available here https://play.google.com/store/apps/deta … e.swiftkey you can make the keyboard smaller and a split keyboard makes it easier to type with your thumbs in horizontal mode.
You could also try a semi-transparent keyboard

Please note: Its not perfect, but you can now create invoices etc. on the move - hope it helps someone.