Wrong priorities
-
This is a mild post about criticism. I do think the Vivaldi team achieve a lot of great things and I can understand they might be a little bit understaffed, also at the lower end of money and partners compared to for instance Google Chrome.
I also understand this browser is young compared to other browsers and their vision is to have as many features as possible on the market.I enjoy most of the features included in the browser. But they wait too long to fix some of the current bugs. This is not necessary about resources but about priorities. I have been in the Linux community for some time and I see a form of mentality that is clearly about adding features before fixing the bugs that came from the earlier patch. It's funnier to add features than fixing old bugs. I think this mentality is partly wrong and overall hurt its popularity and users.
To mention a few (these might not apply for everyone).
- Stacked tabs goes out of order after moving it to another place.
- Mouse cursor goes sometimes hidden.
- Can't add shortcuts to extensions.
- The browser crash/becomes slow under a lot of pressure.
What I wish to say is: What if the Vivaldi team take two steps back and one step forward instead of three steps forward and one back? Just for a short period of time to priority the stabillity, speed and bugfixing more than normal. Put more men on the bug-reports. I love features, but bugs kills happiness really easily.
Edit: It's also worth considering improving the current features instead of adding new. Sometimes that can be of greater importance.
Thank you for reading.
-
@masterzelex A while back the team did spend an entire release cycle focusing more on bug fixes and improvements rather than new features.
They also decided to spend a cycle improving window handling, which led to performance improvements.
The devs are aware of the need to improve performance and fix bugs. They also have their own idea of priorities and what with them having careers in the browser building field I would defer to them to make those decisions (though I agree it is very tempting to say that they're doing it wrong when one of your pet bugs goes unfixed ).
-
@lonm It's great to hear they spent an entire release cycle on that.
Yes, I'm fully aware of that devs have a mind on their own and they might get more motivation and workflow if they can decide a little bit themselves.
One of the reasons why I put this in the forum now is because these bugs have followed me in months, meanwhile I see the gap between Vivaldi and other browsers in terms of features is very big. Also, I want to mention this is not about me, but people in general. I'm sure other people notice bugs, but perhaps not as much as me. Perhaps they care less too.
You can call them pet bugs, but they are definitely not small of size or importance. Another example is that tab popup thumbnails hang sometimes.In my eyes, the new features are more or less details and smaller compared to the past which naturally should mean they slow down and take a proper look back on what they actually have added and what is not good enough. The goal should of course be a rock-solid browser, chrome have had this goal from the beginning and to tell the truth, it works. This is a great browser, especially for power users and it's really good for people in the Linux/GNU, Mac and Windows environment that likes customization, features and development/research.
-
@masterzelex Yes, I understand what you mean, and agree with that, at least partially.
I had already written something in one of the old "team blog" posts about the need for more debugging, and focus on low priority issues. Olgaa had upvoted it, I don't know if they discussed about it internally ^^
I also agree that more polish on a feature would be very useful.
For example, a new big feature is added, a lot of time must have been spent by the devs on it. After a few weeks of usage I find that we miss 2 or 3 very small little things to make it really great... But they are already working on something else, and give the feeling that they wont come back on the previous feature for a long time.... But all this is always easier to say from an external point of view:
We don't have all the elements to estimate what is the best strategy for Vivaldi, what is the real amount of bugs or tickets they have to deal with, what is the real effort they put in debugging vs what we see as end users, etc...
Moreover, the priority is different for every one: our "pet bug" may be insignificant for someone else, who is in fact dying for the next feature they are currently working on.Not an easy problem
-
My words, I was pointing the same thing few days ago. Freeze inventing new features and just keep bugfixing and polishing for few months. I believe that bug list consists of hunders of issues.
-
@guilimote Speaking from my own viewpoint, I don't face any unfixed bugs. None. That doesn't mean there are none, just none that impact my usage pattern.
On the other hand, the developers have little placards posted in every workspace they use in the US, Iceland and Norway that say "Kill all Bugs." Obviously it is an emphasis for them. To date, over 38,000 bug reports have been received. Some thousands of them remain unfixed. This very small team, which still costs more to operate than the browser receives in income, fixes between five and fifty bugs every single day. Today's internal tester version contains nine bug-fixes. However, for instance between early Friday and so far into today, 96 new bug reports have been received.
Some bugs are "repaired" merely by continuing existing work on features. Some disappear (while new ones are created) each time Chromium updates. The rest are prioritized and worked on by available personnel, while the ongoing work of actually building the browser, which is far, far from finished, goes on. Were all work stopped to repair bugs and polish existing features, the browser would, for all intents and purposes, never make any more progress toward becoming a finished product. It would always remain half-done.
What is desperately needed is for the browser to become self-sustaining. For that, it needs users. Every feature-add results in press releases, new eyeballs, and a surge of new users. To my knowledge, no bugfix has yet added any users, although it has from time to time resulted in users coming back or spending more time with the browser, or finally converting to it as default. But what really moves the browser toward sustainability is moving it closer toward its goal of the complete feature-set that has been envisioned for it.
Just some comments on the realities of the matter.
-
@masterzelex See my comment to @guilimote just above this one. I also wanted to comment that we testers receive an updated version five to eight times per week usually. Something like 90% of the changelog on each update is nothing but bugfixes.
-
@ayespy said in Wrong priorities:
What is desperately needed is for the browser to become self-sustaining. For that, it needs users.
OT:
I know, not the time and not the place. But I observe a great willingness in many users to contribute to Vivaldi and thereby, development. I read about Jon's position toward donations. I imagine most would not mistake donating with owning the company or having any influence on further roadmap painting.
I'd like to contribute to Vivaldi by using affiliate links - sadly, the search engines I use (and my browsing style in general) does not generate revenue. As paying Opera buyer (3.10, that is, IIRC ) I'd gladly donate - if Vivaldi let me And I'd bet I'd not be alone on that... -
@ayespy Thank you for your answer!
I know the team is small and they do their best, but having some figures help to understand into which proportions... Which make us feel even more how incredible their work has been so far!To date, over 38,000 bug reports have been received. Some thousands of them remain unfixed. (...) between early Friday and so far into today, 96 new bug reports have been received
I was assuming something like that, it does not surprise me. But it does not mean the process can not be improved (it does not mean either that I know the best way to improve it ^^)
It would always remain half-done.
The enthusiast part of me finds this very sad, put the other part knows it is true, and you have perfectly explained why.
What is desperately needed is for the browser to become self-sustaining. For that, it needs users. Every feature-add results in press releases, new eyeballs, and a surge of new users.
I hadn't thought about that, but yes, it makes sense. It is exactly things like that that I meant when I said "We don't have all the elements to estimate what is the best strategy for Vivald"
from my own viewpoint, I don't face any unfixed bugs
Yeah but aren't you cheating a little? ^^ I assume that your bugs are getting a higher priority than ours... And I would understand that perfectly (better and more direct communication, easier for the dev or you to get / give more info, quicker testing loops, better filled reports, etc...)
-
@guilimote said in Wrong priorities:
Yeah but aren't you cheating a little? ^^ I assume that your bugs are getting a higher priority than ours... And I would understand that perfectly (better and more direct communication, easier for the dev or you to get / give more info, quicker testing loops, better filled reports, etc...)
Actually, no. My oldest bug that no one has done anything about is over three years old. The reason I encounter few/no bugs in my daily usage is merely that my needs are quite pedestrian, limited mostly to point, click, and look. I'm not a keyboard demon, gamer, techie, downloading fanatic, tab-hoarder, media consumer, or other "power" user in that manner, nor am I afflicted with a crap system or OSX. I'm just lucky that the workflow design features that work so well for me are there for the same reason my workflow developed that way - because of the heritage of the original Opera design. Now it's true that being an internal tester, I do get first peek and feedback on new features, so of course as one voice out of about 70, I obviously get more attention that way than I do as one out of a million users.
-
Ayespy, thats all good what you have written. You wrote that bugs are fixed all the time, thats good. But understand, that with adding new features, new possibilities for bugs are coming. And therefore the longer existing bugs are delayed to be fixed. My view is instead inventing new and fixing bugs side by side, concentrate all resources ( as the team is small) for some time only just for fixing existing list and trying to smaller it. I'm not a professional programmer, I'm just messing around with C# in spare time, but moreless I know how development works.
Were all work stopped to repair bugs and polish existing features, the browser would, for all intents and purposes, never make any more progress toward becoming a finished product. It would always remain half-done.
But it will not meant to completely stop inventing new things, just for some time, month, two.
Just don't get things wrong, I mean whole V team. I just wouldn't be happy if the whole product and way of developing will end like Windows 10. Their Feedback Hub is growing and growing and they keep inventing new things, mostly halfbaked, which causes new issues, and long serious issues are not fixed, because they have to fix bugs which occured from new features.
-
@ayespy said in Wrong priorities:
nor am I afflicted with a crap system or OSX.
Apart from being afflicted with OSX (which is a mostly pleasant experience ) - I experience very few bugs. Mostly using the mouse/touchpad for clicking and scrolling and the keyboard for opening/closing of tabs, I'm fine. Even Youtube (mostly) runs, haven't had a non-working video for quite a while now.
I'm just lucky that the workflow design features that work so well for me are there for the same reason my workflow developed that way - because of the heritage of the original Opera design.
+1
-
I tend to build my workflow around the bugs. If something does not work or does not work properly, then it makes no sense to continue using it in that way.
So my experience is mostly smooth. The bugs mentioned barely affect me or at least do not get in my way.
That said, it is a tad presumptuous to claim that the team has their priorities wrong.
-
By all means, I am very happy Vivaldi exist and I truly understand how small in size the Vivaldi team is. Also a little bit about how the economy works. I'm a computer science student and I understand how time- and resource heavy de-bugging and testing can be. It's scary.
I look at the Vivaldi-browser as a part of the Linux community to tell the truth. Many similarities. Both have a high learning-curve and both are for power-users. The Linux/GNU desktop-environment is very small compared to Windows and the same is Vivaldi compared to Google Chrome. Nevertheless, I believe in the Vivaldi team for the same reason I believe in the Linux/GNU community. This post was fundamentally about resource-spending and priorities which is never very easy, but among smart and hard-working people there will always be hope.
I do not work in the Vivaldi-team. It's incredible limited what I can do to help. I honestly care about Vivaldi's future though and I would like to say I wish the best for the web-browser. I should be careful to "recommend things" and say too much without being a part of the Vivaldi team and having a deeper understanding, but my best advice the way I look at it is, to keep working on the desktop-browser more than anything else.
The moment you overdo all types of side-projects such as email-service, phone-browser, sync and all these fancy things, that's the moment the browser will lose too much momentum and be full of bugs, messy code, bad comments, not re-usable code, bad structures, bad communication, bugs that will take 20 years to fix etc. As a result, the team might give themselves a lot of extra work in the future. One of my motto's is "to do things properly once and don't touch it again", that being said, improvements are always good and good code will make improvements easier in the future.
The last thing I want to say is: small details do matter for everyone. Doesn't matter if it's code or bugs. The browser is not finished yet and I respect that, sounds good. But details matter. Vivaldi decide how fast the feature-train goes.
Thank you.
-
Sorry, I apologize, but I can't let this rest here.
@masterzelex said in Wrong priorities:
By all means, I am very happy Vivaldi exist and I truly understand how small in size the Vivaldi team is. Also a little bit about how the economy works. I'm a computer science student and I understand how time- and resource heavy de-bugging and testing can be. It's scary.
The moment you overdo all types of side-projects such as email-service, phone-browser, sync and all these fancy things, that's the moment the browser will lose too much momentum and be full of bugs, messy code, bad comments, not re-usable code, bad structures, bad communication, bugs that will take 20 years to fix etc.
Mail was an integral part of the Vivaldi browser concept from before the time it ever saw the light of day. It has been under development for nearly four years, now. It is not a side project. Sync, too, was under development from before the first tech preview of the browser, over 3 years ago. It is, as user demand has demonstrated, considered by most nowadays as an essential part of every browser. It was not possible to defer it.
Mobile is the largest as-yet-untapped market for Vivaldi. It is essential to develop, not a side project. Back when Opera was young, and before mobile had the penetration into the market that it has today, There were more users, and more income, from mobile than from desktop development. It is true that Vivaldi's first emphasis is desktop. But if it is ever to be profitable, it must penetrate the mobile market.
One of my motto's is "to do things properly once and don't touch it again", that being said, improvements are always good and good code will make improvements easier in the future.
This is all l very well and good if the entire project is in-house. Unfortunately, the every-six-weeks introduction of a new Chromium version means that everything must be at least touched, and possibly re-written, every six weeks at minimum.
That's all I have to say on the subject, for now. Every day, lately, I am looking at test versions that a new Chromium intake has broken. "...don't touch it again" is not, and for the foreseeable future never will be, in the cards for Vivaldi. Thanks for your attention.
-
@ayespy said in Wrong priorities:
Every day, lately, I am looking at test versions that a new Chromium intake has broken. "...don't touch it again" is not, and for the foreseeable future never will be, in the cards for Vivaldi.
Is this why there are so many regressions?
-
@chrisvio It's a chief contributing factor.
-
@ayespy said in Wrong priorities:
,,, It's a chief contributing factor.
It's ironic, but back in the MyOpera forums a few years ago when the controversy was raging over Opera abandoning Presto in favor of Blink, this very thing was one of the arguments I and many others raised against the rendering engine change: dependency on another party for an important part of a browser means you no longer have all the keys to your product in your own pocket... you have lost control of a significant part of your destiny.
I recognize and accept the reality that it's simply too massive a job any more for a company like Vivaldi (or even Opera) to maintain one's own rendering engine and gain its wide acceptance by website coders, but one of the true costs of using somebody else's engine is also now becoming apparent within the steady parade of troublesome engine updates. It's a tough situation...
-
@blackbird Of course in those days, had Opera doubled the size of its core team working on Presto, there's every chance it could have kept up. It already had a mature browser engine of its own that it had developed over a 20-year span, arguably the best engine in many respects, and it had plenty of money to pay as large a team as it needed to keep pace with the web. However, the money-people behind the browser, who had a lot of voting shares, didn't want to do that. They wanted to do what they felt would make them the most money - sell the company. To make a company sale more attractive, lots of corporate types think the wise thing to do is to cut personnel. It makes a temporary, but strong, impact on the profit and loss statements. And that is what they did. Slashed staff (Including the entire core team) and sold out. I'm not revealing any secrets here. This data has been known for years.
It's sort of the mirror-image of what happened that gave us MS DOS rather than CP/M as the dominant operating system core in the late 80's. CP/M was arguably the superior system, by a lot, but its authors refused to sell to Microsoft. MS was, on the other hand, able to take over IBM PC DOS - an inferior system and ripoff of CPM, but one they could build personal computers on. MS was a ton better funded than Digital Research, and not the least bit averse to cutthroat trade competition, while being able to afford marketing, and they took over the market, squeezing the original CPM out entirely by 1984.