Improving the core of an online service should cover four major and distinct areas: (a) bugs, (b) operational usability, (c) feature requests and (d) pricing & billing. Each of those has its own specifics and this is why their require different arrangements of community involvement. For example, addressing bugs should allow both public and private communication, because a user might not want to share her work in progress. This is why most services have both the private email and public forum channels.
And while more often than not the communication media for bugs and feature requests are separated - just as we have them separated with the recent introduction of the community Wishlist - that is not the case with operational usability and pricing & billing.
I regard this as a major error of ommission for any online service. I wish there were individual communication media for those two in Webflow.
Let me elaborare on the operational usability. What is the difference between feature requests and operational usability requests? Well, a request for a native show/ hide widget is a “feature request”. A request about placing the page preview button on the right, instead of the left, is an “operational usability request”. (Maybe “operational usability” is not the best naming, but nothing better comes to me for the time being).
In other words, new features are things which enhance the scope of what is possible to build with the tool; operational usability is about how easy and fast it is to use the tool.
Therefore I propose that we have a different feedback space for operational usability. Currently it’s all mixed in the Wishlist and operational usability remains somewhat left out. What I mean is that operational usability is much more often about “usability bugs” so to say, than it is about building something new, and bugs are by definition annoying and killing productivity, and should be addressed quickly.
Separate space for operational usability might also, possibly, urge some sort of accountability on behalf of Webflow. I would guess that even the most enthusuiastic believers in Webflow have already started to see its evident decay and the “the Webflow geniuses knows best what to do” and “It takes time” mantras are not working any more. We do need all usability glitches and half-baked solutions exposed and acted upon, in short-terms. Should I be waiting for “Interactions 2.0” to appear before I have some essential issues in UI fixed and others streamlined? UI glitches are just like bugs in code - they are a matter of poorly delivered service, so there’s no excuse for waiting for them to get fixed. This is the huge difference with features requests - bringing about a new feature does take a lot of thinking, prototyping, tweaking, implementing, etc and that’s just fine, it does take time. But not having a properly set process for quality control over delivering UI is not a matter of excuse.
I think such operational usability feedback space should come together with some transparent policies on delivering UI changes - e.g. a 10 day testing period, in which every Webflow user would be automatically invited to give feedback.
Webflow’s current attitude of "we know best and you’ll have to adapt to our “good practices” is insulting and childish. (And shocking, of course, given how it comes from the same people who initially built this (less and less) amazing product.) Webflow guys, I wish you could differentiate between the situation when the patient is not the one to decide what is the right treatment and the situation when the patient is the one to know best where it hurts. The doctor does have to ask the patient where it hurts and listen to him. There’s nothing wrong in involving the community in testing and streamlining the UI. Testing and streamlining the UI is not the same as developing new features. The “If I had asked people what they wanted, they would have said faster horses” proverbial saying is relevant in the case of developing new features, but not the case of UI.