I totally did not check the date of the original post. Made a long response to the OP, which is surely moot/irrelevant at this point. Oh well. I’ll just wrap it in summary, in case anyone actually wants to read it…
Response to necromancered OP
I answered ‘No preference’ simply because there was no option for ‘It’s okay, but maybe a bit risky, and so I would make it low priority’, which IMO is a bit lower than ‘It would be nice to have’.
Personally, I don’t see much of a ‘use case’ for it. Or rather, there is a use case, but I don’t think there would be that many people who would actually use it. Of course, I could be wrong, but right now I just don’t see there being a widespread demand/purpose.
Plus, I could see this as being quite a significant development task, probably requiring quite a bit of new design of both code and UI. If the design is not well thought-out, it could easily end up becoming a development resource sink-hole. But that’s just my personal guess – I could easily be wrong about any of that.
If there was an existing library or tool out there that already had well-proven support for this, and it could be adapted by BP, rather than developed from scratch, then maybe it wouldn’t be quite so risky. But I have a hunch that due to BP’s already quite unique customer/user-base and their already quite customized UI, that even if there was some existing tool out there, it would still have to be customized quite a bit, and thus the overall risk might be about the same as if they were to develop something from scratch.
With all that being said, I can predict that eventually, at some point in the future, Bunpro will almost certainly have to ‘take control’ of their current text-input feature-set and develop their own custom library of input tools/widgets, so that they can introduce new innovations with confidence and control. I mean: Not just tweaking things here and there and hoping it works without breaking something else, but being able to introduce new features that they will be confident that they work well together with all existing features.
But I just don’t know if the BP software-base is at that point yet where such a core feature can be developed in that confident way.
Don’t get me wrong, I’ve been constantly impressed by what BP has done over the years. But I still feel plenty of ‘rough edges’ in the UI, the overall site and app, the data organization, user-feedback/bug-reporting, etc. If I could make one recommendation for development, it would be to take some time to polish-up and clamp-down on improving development quality and internal testing.
Specifically, if it’s not already being done, I might recommend building up a scaffolding of automated testing (from unit testing to acceptance testing to integration testing), and having a system of automated-integration.
Basically, having an automated system which builds and deploys the entire site/app at least once a day (to a non-public development server, for example), and which will fail-fast whenever there are, say, any unit tests failing.
From that foundation, do something akin to test-first programming: 1) where each new feature is first supported by tests (which initially fail, because the feature doesn’t exist yet, and are programmed in order to make the tests pass), and 2) where any changes to existing or ‘legacy’ code is first supported by some tests which exercise the existing functionality (if such tests don’t already exist), and any changes/refactoring is done such that it doesn’t break this test-scaffolding.
Obviously, I don’t know to what extent you guys already do something along these lines (and there are many variations of how to do it of course, the above is just an example), so maybe the above advice is not really necessary.
I’m just saying that, while I love all the progress BP has made, to me it doesn’t feel as solid as I would expect from a project which fully embraces that level of commitment to automated testing/integration/quality-control. That’s why I’m a bit skeptical that the system could really afford to take on the potentially big risk of revamping such a core component as the text-input controls. (Again, I could easily be wrong. This is just my own impression as a user observing from the outside.)
Sorry for long, ranty comment. Just brainstorming thoughts, so I won’t bother trying to edit for brevity.
Given the Bunpro team’s commitment to listening to customers and their track record, I’m confident that no matter what, at the end of the day, they will manage to develop the site/app in an appropriate way that will overall be a great thing! I’m just raising my ‘devil’s advocate’ cautions of potential hurdles and pitfalls that might cause such development to be more painful or take longer than originally hoped for.
Cheers!