I’m a solution architect and have built with the team a new app using frappe. When I did demo to business stakeholders the thing they commented on was that the list view columns did not align/look-good and the roll-over text was broken. For this reason ( they do not see the great engine underneath ) they rejected the platform as “bit-broken/not ready”. I have documented all the issues in frappe/github under user “ollyboy” but they don’t seem to get any traction. Do others think that the frappe team should do a good review of UX/UI? Its 90% there but the last 10% will prohibit its growth and consideration as a true alternative to SAP/Netsuite.
With a myriad of proprietary and open source ERP products to choose, what led you to Frappe as a development platform?
My job for over 30 years was to find the best IT solutions to business problems given - time, cost, quality. Always considering the factors of “vendor-hype”, “regret”, “fail-fast-exit” and “developer-availability”
- I choose Linux over Microsoft server tech way before GC/AWS
- I choose Magento e-commerce open-source over expensive property platforms
- I choose WordPress over expensive CMS systems
I did not always choose open source. There many are times when paid solutions/vendors were the best options.
Frappe has a chance to be the next Magento/Wordpres in its domain ( Linux is in a different class ). That’s why I invest time in it.
SAP/Netsuite/Dynamics are all super polished ERP lego boxes. Have implemented them all. They can do anything but the true cost is in the configuration and customization. Consultants are $1000/day in western countries. Frappe has a chance of breaking/disrupting this. But - Toyota didn’t break into the market by building cars with terrible paint jobs. Look/feel matters, reliability eventually built reputation but that is not what won initial market share.
These forums get a couple posts a week of the format, “ERPNext will be the next superbigthing if somebody (other than me) does X”.
I’ve never personally noticed problems with listview column alignment or rollover text, but if I had there’d be a pretty clear pathway forward. In open source, you vote with pull requests.
peterg - I have sent simple pull requests under username “ollyboy”. Also have had 2 two bugs fixed in config and charts that I identified and documented as per guidelines. My skills are not strong enough to find/fix the UX issues I submitted. You seem to indicate that these would be easy for you to fix, would be useful if you could comment on the actual issues and provide some hints/advice. I am prepared to put the effort in, was hoping for some help/guidance from this forum.
Can you give some more details , possibly with screenshot?
I worked with SAP almost 20 years now, I like open source and love ERPNext so much, tried to migrate some SAP features to ERPNext, unfortunately some of them not accepted into core due to different reasons. anyway, let us try our best to improve ERPNext together.
That’s great, and you’ll find both the community and the maintainers very supportive if you lead with that mindset of pitching in.
I’m definitely not saying it would be easy for me to fix. The nature of the problem isn’t clear to me, and even if it were I’m only beginning to feel comfortable in Frappe’s complexity. That’s part of the challenge here: fixes that seem very simple often have very unexpected entanglements. I saw that you posted on github, for example, about how fields respond to change versus defocus. I agree completely that the way things work right now isn’t ideal, but because of the way that Frappe’s event architecture works I suspect that it’s not a simple fix.
As for the specific issues you’re highlighting here (column alignment and rollover effects), I’ve never noticed anything myself. If you post steps to reproduce and some pictures like @szufisher suggested, I’ll certainly be interested to take a look. That said, with the new UI coming out in V13, I wouldn’t blame the maintainers if they were reluctant to spend much energy in this direction.
Please share the version you tried, tested and presented to the client.
Did you do a detailed testing before the presentation?
Can you share the link to the pull request?
Giving detailed information in a post is the key to having good collaboration with the community members. In open source we should not always rely on the core team.
Appreciate that you have made a pull request but we do need to push it many times to get it upstreamed.
Example: customer ledger summary report is broken since long time in v11 my developer pushed it upstream as hotfix. Its been few months and it’s still not merged. Today after updating my clients server I had to manually fix that report. So yes sometimes it can stay there for long time until pushed multiple times.
I cannot blame core team coz they have their own responsibilities to fulfill.
I agree that erpnext/frappe gave potential to replace Sap/dynamics etc. But it is an open source project and the core doesn’t really earn much.
Let us work on the bugs together. We have been deploying Erpnext since 4 hours now and have done more than 30 medium size deployment, many people have told us the our UI is not good but that have never demotivated us to promote erpnext.
People will have their opinion but it all comes down to how much they’re ready to pay.
You can give more presentation on Erpnext and see what others in your region have to say about it.
Update: I see you Raise multiple issues here most are not bugs but deployment faults which have nothing to do with frappe hence they might have been ignored and one is tagged as feature request which is not so easy to do for the whole project just because one person doesn’t like it.
I hope you’re aware the its a open source project and any chance you want should be catering to general use case and not just one person point of view.
I also see a pr here it seem to have failed since ci test hence now merged.
If you need those changes then you can take full course on erpnext and frappe and create an app that will overwrite all those points that you raises issues for, that way it will be faster for you instead of waiting for the core team to accept the pr.
Good luck with your projects.
Hi, here the issues logged in git. Some have short video:
First problem the user complained that they could not see the value of a column in the list view ie “Commonwealth bank of Austalia”
When users edited a field without tabbing to next field they had to hit the save button twice
I will check the quality of the other issues and post them later
Here is another example of UI/UX issue.
I put up a PR for the first one.
peterg - one-liner, great work!
List view is such a fundamental component of frappe, this will be a great improvement. It’s crazy we can adjust the column widths in the child list view but not in the main list view.
You are correct about pull-requests, they are obviously prioritized way above “issues”. Got one of mine approved into dev branch yesterday, only a few days after submitting. ( It to was a one-liner after review )
Great initiative @peterg
One of the most irritating part is the reports frame section. The vertical and horizontal scroll bars are within frame which rests within browser scroll. It would be great is the height is adjusted so that only browser scroll bar is used. Max rows per view is 9. To view further the frame scroll bar has to be used. Keyboard arrow keys move the whole page, not the frame which keeps displaying 9 rows. Am not sure how the width can be adjusted as there can be many columns that can’t be fitted in screen. For a client we have been trying to get it done but no success as yet.
Fixing it will surely help users quickly scroll up and down either with mouse or keyboard.
This I have observed is few V12 instance. Some V12 work fine with one click, others don’t do anything until Save button is clicked 2nd time. Have a hunch that it’s more to do with server response than the software. Maybe what I think is not true and there is some error in code.
Indeed, and the same issue comes up under some circumstances in list view as well. I tried to dig into it once but it wasn’t a trivial fix. There are a number of different max-height directives in the CSS that conflict with each other, and it’s hard to pinpoint where exactly different constraints kick in for different data loads. I intend to give it another dive, but I’m waiting for the new UI to land on v13 beta.
.primary-action it triggers the second time you click but not the first. I suspect there’s something that gets triggered by a defocus event that’s interfering, possibly in a race condition (which would explain why it happens sometimes but not consistently). I’m able to reproduce on v13-beta, fwiw.
Muzzy, on your reports issue, have you logged frappe issue, do you have screenshots. Is this a fundamental high use UX/UI problem?
Right, that’s by design. It would be undesirable for Frappe to bubble up a field change event on every key stroke. Defocus is probably the right time to do it. What’s unexpected here is the need for a double click on save. The first click triggers a defocus event, as it should, but then the click event itself gets lost.