With the renewed interest in Sailfish from the JP2 campaign, we’ve seen some complaints about the slow pace of “changes" since the JP1.
While I’m all for conservative change, it seems to me that Jolla design changes are mostly motivated by necessity (either from customers in car industry, or from the needs of Aurora when that partnership was in place) and not much by design studies (identified sore points). – This is totally subjective, and does not reflect the reality at Jolla but my own opinion. –
As a community we have a great way through this forum to participate in the development, and therefore to the design process itself.
What I would like to propose is a formal Sailfish Design Improvement (SDI) process in the manner of these collaborative efforts :
a formal pre-SDIP template to be filled by anyone (see below)
approved pre-SDIP will get an SDIP number
forum tags for pre-SDIP and SDIP
optional wiki page to collect all the pre-SDIP and SDIP
Administrative work for the community would be kept minimal, merely guiding newcomers to fill their pre-SDIP correctly, give an incremental number to every valid pre-SDIP in order to promote them to SDIP.
The main gain would be two-fold :
Easy, peaceful and constructive redirection of newcomers with great ideas to either write or read the corresponding SDIP
Some constructive design options for Sailfish/library/app creators to choose from
Posting this proposal to see if there is traction in the community for such a process, since I’m unreliably available and won’t be able to shoulder any of it past the initial phase.
—
Minimal SDIP template
Problem
What we have now (including screenshots)
Comparison: how are they doing it on other platforms (including screenshots)
Proposal (including wireframes)
Jolla did actually do studies on usability, and all changes that came from those were met with criticism from the same people who always claim there are massive design problems, yet never seem to be able to point out a couple of examples or ideas for further improvement. I think your idea of a streamlined process definitely holds merit, but based on the already almost complete lack of concrete examples/proposals so far (other than “it SUX lmao”), I don’t know if it would be able to change much, if anything.
I have not found information on Jolla’s design decisions and would love to get a link or direction on where to search if you can.
I’m of the opinion that baseless criticism is good, as long as it is tunnelled into a constructive process. The main idea is to redirect the “it SUX lmao” guy into a pre-SDIP, where the trolls will get discouraged by the task of formulating a formal complaint, but a valid issue will get formulated in a way that can be acted upon by the community.
If my memory don’t fail me completely, at least in the early days of TJC, Jolla posted about their A/B-testing with results when people complained some design change.
Indeed, both link are good examples of constructive feedback that is not easy to act upon (as a community, dev or for Jolla).
Scrolling those threads, I found several different ideas of interest that completely lack visibility, or a neutral structure that would enable the community to start looking for a solution, or to dismiss it as a non-issue.
I failed to find where my proposal repeats the other threads.
I’ve found time to read the link. The material from Jolla is great, unfortunately pertaining only to one part of the design process : some feedback on the best design. The four offering seem to converge to a full solution, something like asking users if they prefer a partial or full implementation of the idea ?
What I’m trying to put in place here is the very first step of design. The impulse to change something, and put that to good use by going the extra leg of formulating that into something useful, that is a proposition (problem → offered solution) to be discussed, snoozed, refused, retaken with a different solution, modified, and hopefully sometimes accepted.
This is not only for Jolla, but also for every app made with Silica. It probably will be more useful to community than to jolla in most cases.
A process on itself has no value for us user. My experience with some different software worlds say me, many user want UI changes only when there was a real problem behind. In other cases like changes of the corporate design, vendor design, design trends (more colors, less colors, more icons, more creative drive ..) users often are stressed for (in their words) “nothing”.
So before create a process please let’s talk about what you found as deficiencies.
Unless jolla themselves are serious about doing something about the design -assign a peson to do it- whatever processes the community follow has no value and its a waste.
There have been initiatives like paper cuts, we have pointed out inconsistencies and no changes have been made. And the visual overhaul is a different story alltogether.
Yes, this kind of stuff is for the dev s, so that they can make better software for you user.
There is a gap between paid/closed source and free/open source worlds. In the closed ecosystem, when you are not happy, you buy something else or live with it. In the open source world you can usually find alternatives because if someone is not happy he can just fork and modify by himself.
Jolla has closed and open parts, and all the work from the community, apps and patches, is open source.
While the official apps follow the principles with grace, most of the community apps struggle in some ways to adapt those principles to their use case.
I was actually trying my hand on some app (don’t expect it, I’m not a Qt dev, I’m on full-stack scala + scala.js stack), but found myself lacking in knowledge on how to design it. Looking around at what exists, I saw the wide array of use for pulleys, pages, etc.
I also helped to shape that kind of process at my work place a few years ago (not for design) so I saw a need for it here.
This topic is about a standardized improvement process,.
Communities are great at pointing problems, but the solving is not always trivial, sometimes needs more input, or some user feedback, interaction between the devs and the users.
Jolla solves the issues they have by themselves and have done great so far even collecting feedback as shown by a link above. They could also profit from a knowledge base of what solutions the community devs have come up with.