A few thoughts on Vivaldi development priorities
-
@gmg & others.
I begin by offering the Vivaldi Team my sincere congratulations. You've created a universal tool for all cultures & languages. It must be like taming an octopus.
I know you must have some plan that includes function requests, reported bugs, innovative improvements & more that I'm not thinking of. Different groups will always have different priorities but -- at 30k feet -- you, developers have your own as well.
I know there is a plan. The problem is I haven't the vaguest idea what it is. The developers often cite user's needs as a guiding light.
Really?For example, integrating browsing // capturing data, email & calendars is extremely useful IMO. You've taken 3 daily functions & housed them under one roof. Some of those functions are more developed than others which is understandable.
Browsing, for instance is far more advanced than email which is still in beta. I think email deserves more attention. For me, further development in the email module is not a matter of bells & whistles. It's a matter of function, efficiency & practicality because I use it every day. Even if I don't want to communicate with someone, that someone may want to communicate with me. The problem is how to handle all the incoming.
I guess -- no, I know -- that I am suggesting that more focus be placed on developing // refining Vivaldi's email functions. Currently,
it appears to be a novel with only a few chapters. Bringing it up to speed will make Vivaldi a trifecta. So...... does anyone know where email development is on the grand "list"? I've got to imagine that I'm not alone in thinking about this. If this post serves a small nudge in that direction, then I've accomplished my goal.Thank you.
-
This post is deleted! -
I wouldn't worry too much looking about this not being a priority looking at the changelog, but I'll try to ease your worries
I was reminded by your comment
@janrif said in Yayβ¦ it's Friday β Vivaldi Browser snapshot 2652.3:Thanks for this update, Not to appear ungrateful, but can you focus on Mail for few weeks//months? Tks
So I looked at the latest few snapshots and provided a summary there
@gmg said in Yayβ¦ it's Friday β Vivaldi Browser snapshot 2652.3:
@janrif:
Not sure who gave you the idea that we're not
If you go through the last snapshots you might notice that Mail/Calendar not only pops up every snapshot (apart from a few single fix/security fix ones), but the following snapshots have all had more Mail/Calendar fixes than other fixes combined- March 25, 2022 - Syncable Search Engines (2621-3)
- March 29, 2022 - A few small changes (2623-4)
- March 31, 2022 - Mail and calendar improvements (2623-10)
- April 1, 2022 - Getting Closer (2623-12)
And even the other ones there's still a long changelog
- March 21, 2022 - Underlying mail changes (2617-2)
- April 13, 2022 - Lots of crash fixes (2643-3)
And these are all just within a month (last ~31 days)
Mail/Calendar is a key feature and we're working on it. It's getting close.
For me, further development in the email module is not a matter of bells & whistles. It's a matter of function, efficiency & practicality because I use it every day...
...I've got to imagine that I'm not alone in thinking about this. If this post serves a small nudge in that direction, then I've accomplished my goal.Absolutely, always nice to be reminded and I know you're not alone.
But yes, of course, nudge accomplishedP.s. what's your pet peeve at the moment? Your most important thing?
-
@janrif It may help to put the mail efforts into perspective to know:
Mail client development is a specialized skill. A small minority of software developers in the world know much of anything about it. If one wants to develop a mail client, one has to hire or train mail client developers - not software developers in general or browser developers.
I don't fully understand it myself (obviously - I'm not any kind of developer at all), but I do know that mail is an incredibly complex function, requiring coordination of multiple KINDS of software functions. It has to do word processing; web rendering; database building, maintaining and searching; mail-specific communication tasks requiring unique port recognition, call-and-response protocols, security of access, messaging, file transfer, etc.; filtering, tagging, labeling (and indexing all the above); and more; and it has to be able to do all of these things at speed with the most efficient choice of, and prioritization of, various kinds of protocols and processes. Any adjustment made to one aspect of this collection of functions can break numerous others. It's kind of an art, really.
Vivaldi has a very small development team. It has a much smaller mail client development team. If there are, let's say, 20 developers and 3 of them are mail developers, you actually can't tell the other 17, "Hey! Drop what you are doing and work on mail!" They literally couldn't if they wanted to.
As to priority, before the very first Technical Preview of Vivaldi saw the light of day, mail was already being worked on and a rudimentary version already existed. The team dedicated to mail has never stopped working on it from that time to this. I'm pretty sure Jon has even added one (maybe two?) people to the mail team in the interim. But it is far and away the most complex aspect of the whole Vivaldi browser effort, pursued by (necessarily) the smallest crew.
So believe me when I say, what can be done on mail is being done, all day, every day. I'm pretty sure that will always be the case.
This reflects my own imperfect understanding of what's going on behind the scenes, and it comports with what I see coming out of the team daily in our internal testing updates.
-
@gmg said in A few thoughts on Vivaldi development priorities:
P.s. what's your pet peeve at the moment? Your most important thing?
For me, reliable label/filtering. (But I didn't test recently because I moved my mails on M3 :D)
-
@hadden89 said in A few thoughts on Vivaldi development priorities:
reliable label/filtering
I remember Eudora's filtering options - now that was really great
-
Each user has their own priorities. I use the mail client, but it is already plenty good enough for me.
For me, customisation is more important: MMB and Toolbar customisation, what to do with downloads, fix find in page, etc.
Other users will no doubt have their own priorities.
-
Funny you should mention labels because that's exactly what I was working on. Quite a few fixes there alphabetized, default labels that are colored and sync to Vivaldi/thunderbird/evolution (note all labels are synced with other Vivaldi instances if they use imap). Combo box in the actions (to pick from list rather than typing in), found another empty label that can now be deleted, @ltgorm fixed labels so they're deleted from the messages when deleting a label from the panel..... I think that's it for now.
-
@pesala said in A few thoughts on Vivaldi development priorities:
Other users will no doubt have their own priorities.
absolutely
EDIT: thanks to @guigirl I realized that we are not in the Mail category here, so I collapsed the original text to avoid hijacking the thread with only mail related feature wishes. The gist was the above explanation of the Kano Model which is a useful tool to determine the focus in product development.
I think we need to think in terms of the Kano model, which separates features into three categories:
-
basic need fulfillers: must-haves, and if you don't implement these to a high standard, people will be dissatisfied. For me, that's just "needs to look nice" where simple stuff like ugly quote levels and line breaks are just in the way of success. I also think the ability to drag and drop an email onto a tag/label/folder falls in this category, as well as the ability to open more than just one mail window.
-
performance features: the better these features are implemented, the higher people's satisfaction will be. From my point of view, this is where "mail organization" falls, which Vivaldi solves perfectly with search and labels. Make it easy to apply and remove labels. M2 had the shortcut l,<number> to apply the respective label (how about l,<text> with find-as-you-type for your label name like quick commands?), you could drag and drop mails onto labels, ... filters could be configured by right-clicking the filter rather than having to go into the settings. I feel Vivaldi could be more convenient here. Oh, and ... contacts. Followed contacts in M2 were great, and many mailers these days make it convenient to access the most frequent contacts.
-
what sets a new product apart though are the delighter features. You don't need many of those, and they don't need to be implemented to perfection to cause great satisfaction. For me personally, this is the direct integration of mail and calendar and RSS (!) within the browser, but I would also like to see some core mail feature in this category. I think allowing to drill down in a search, maybe even including full text indexing of attachments would be great.
Without ActiveSync I will never be able to use Vivaldi for work (and I'm not sure if IT would let me... ) so I feel a little like Cyrano de Bergerac here.
-
-
@gmg said in A few thoughts on Vivaldi development priorities:
what's your pet peeve at the moment? Your most important thing?
It's a toss-up between filters & labels. I think -- on balance -- filters
....and thanks for your responsive response
-
@gmg said in A few thoughts on Vivaldi development priorities:
what's your pet peeve at the moment? Your most important thing?
@wildente said in A few thoughts on Vivaldi development priorities:
what sets a new product apart though are the delighter features
Oooh, oooooh, is this an open mic? Well i'll blurt this out before the MC grabs it off me, & the bouncers strike.
Native, infinite-nesting, groupable, Tree Style Tabs, please.
-
@gmg said in A few thoughts on Vivaldi development priorities:
Funny you should mention labels because that's exactly what I was working on. Quite a few fixes there alphabetized, default labels that are colored and sync to Vivaldi/thunderbird/evolution (note all labels are synced with other Vivaldi instances if they use imap). Combo box in the actions (to pick from list rather than typing in), found another empty label that can now be deleted, @ltgorm fixed labels so they're deleted from the messages when deleting a label from the panel..... I think that's it for now.
??? Have these wonderful improvements already been released in a Snapshot? Or maybe I am confused again or don't know where to look or I don't understand.
Vivaldi 5.3.2652.3 (Official Build) (64-bit)
-
@janrif They haven't even been released to an internal build. He's just telling you things that if I knew them, I would not be allowed to tell you - that is, what he's working on this very moment. To get such from a dev mid-task is a rare privilege.
-
@ayespy said in A few thoughts on Vivaldi development priorities:
To get such from a dev mid-task is a rare privilege.
And I truly appreciate it.
-
I know that for some users the Mail Client is a priority and certainly an important feature. The one that currently exists, although in beta, is functional and sufficient for many users, including myself, although naturally it can be improved (other browsers don't even have this function, remember).
Since I have been using Vivaldi, for almost 6 years now, without any problems worth of mentioning , I have always been clear about needing some patience in its development, knowing that Vivaldi is not a large company with hundreds of employees and developers, but it is also a company that has developers who leave the skin in the development of a unique and magnificent piece of software for 5 different operating systems, apart from ethics and democracy regarding the user at the center of development.
At least for me, Vivaldi only has one flaw, after using it, any other browser seems mediocre and crappy to me. I know, I have tried practically all of them, even the most exotic, over the years.
-
@guigirl said in A few thoughts on Vivaldi development priorities:
Oooh, oooooh, is this an open mic
We are talking about mail, you are totally out of line
@ayespy said in A few thoughts on Vivaldi development priorities:
To get such from a dev mid-task is a rare privilege.
And I truly appreciate it.
Me too by the way
-
@wildente said in A few thoughts on Vivaldi development priorities:
We are talking about mail
Incorrect. The name of this thread is
A few thoughts on Vivaldi development priorities
Nothing about that subject line restricts discussion only to Mail. Furthermore, one of said Devs made this unqualified [ie, unrestricted] invitation:
@gmg said in A few thoughts on Vivaldi development priorities:
what's your pet peeve at the moment? Your most important thing?
So, i did.
-
@janrif said in A few thoughts on Vivaldi development priorities:
It's a toss-up between filters & labels. I think -- on balance -- filters
Certainly bug fixes will always help you but are you still trying to build your self made spam filter?
-
@wildente said in A few thoughts on Vivaldi development priorities:
@janrif said in A few thoughts on Vivaldi development priorities:
It's a toss-up between filters & labels. I think -- on balance -- filters
Certainly bug fixes will always help you but are you still trying to build your self made spam filter?
I gave up! After a certain number (I didn't count), Vivaldi filters go batsh*t crazy & just stop working.
-
@janrif said
??? Have these wonderful improvements already been released in a Snapshot? Or maybe I am confused again or don't know where to look or I don't understand.
@ayespy said
@janrif They haven't even been released to an internal build. He's just telling you things that if I knew them, I would not be allowed to tell you - that is, what he's working on this very moment. To get such from a dev mid-task is a rare privilege.
Well, these (and one more fix for signatures not updating when switching account in settings) should go out in internal build and then to snapshot as soon as @RuarΓ decides to make one.
And who knows what @RuarΓ grand scheme is A mysterious one he isοΈ (To be clear, I'm just messing with him here... but shouldn't be long)