Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
heyheni2169724dthe big problem with many different webapps in a company is that there is no directory of what apps exist.
They usually just exist but nobody got an overview.
So make an website with all served webapps in your corporate network with description what each of one does. And make ot mandatory to update this app directory. Talk to your higher ups and cyber security.
BobbyTables356524dSpeaking from experience, do not develope anything dependent on Excel. Sure it is a great app, but when it comes to automation dont rely on Office applications.
They will end up by asking to recode Excel in web.
"No I want you to present me ALL DATA on the same webpage and a filter, just like Excel, for grou[ping and filtering"
"Oh I can't do cross table here, can you export this view into Excel?"
I've found many times an excel dump is not what users need (but it is what they think they want).
Yep, exactly what I told my self when ( worked exactly on similar project.
Response was : “Yeah here we can filter, then sort”
Me : I specifically added filtering and sorting. What’s wrong with it ?
Them : It’s not like Excel we don’t want to retrain the staf.
Trust me, I feel you, I’m even rooting for your project, because they actually need iot and they don’t realise how much.
But roadblocks will be hard !
Nw.Js for a 'front end', and use semantic UI if you want a semi-clean neutral design and dont give a fuck about css.
@Wisecrack Yes, kendoUI or similar.
But they all have the same limitation (If you can find me one without this limitation, it will replace like 3000 code lines of custom) :
They cannot have Virtual Scroll AND grouping at the same time. It is one OR other.
I need to fucking display 1000 groups, each having 100+ sub-items. (Yes we do it on group level at this time but not even virtual scroll, just pagination)
IntrusionCM327423dWorkflows exist for a reason.
People know what they do and when they do it long enough they feel confident even though they maybe don't have a fucking clue what they're doing.
I think it is not wise to break existing workflows for the reasons you mentioned.
It becomes a whole other thing when you _integrate_ the workflow in the (web-) application you build.
Excel export and import isn't that hard.
Hard is to achieve a state where one source of data is dominant - eg. everyone is aware that the database of the applications is the source of truth, not their locally modified copy.
So the goal with the applications is __not__ to take away Excel and the workflows at the first stage, but to make sure that there is a single source of information that should be the database of the web application.
As soon as you've reached that milestone, you can start working on improving and migrating the workflows.