It's still work-in-progess, but we have some good news. During the last weeks, with a massive help from @nfsprodriver , the new File Manager finally started to take shape.
We will probably release a testing version in the store next week, so you can provide us all the feedback about the new UI and - most likely - bugs
Hi everyone,
I'm Stefano Verzegnassi, I'm 25 and I've been a community contributor and maintainer of some of the Ubuntu Touch projects.
My relevant contribution to the official projects are the Document Viewer (and its LibreOffice integration) and the Terminal app (I've been maintaining it in its latter days, before it moved under the Canonical "umbrella").
Other popular works I've been working on are UT Tweak Tool and InstantFX, which got a decent reception.
Unlike the other stories above, I'm a Political Science student with a strong interest for technology and Open Source. I've been using Ubuntu since 2007 or so, and I started to follow the UT project for its ambitious vision.
While I'm not yet sure of the time I could dedicate to the project, I'd be more than happy to help keeping UT alive. 
Quoting from the Telegram supergroup:
We are within the fair use guidelines outlined by Canonical.
According to the Canonical’s IPRights Policy, there is no proibition against using a "UB-" prefix, which anyway doesn't necessarily imply an endorsement or an affiliation with Canonical. The goal of UBports is to make Ubuntu running on as many smartphone/tablet devices as possible, so we are really within the fair usage of the trademark, as we are part of the Ubuntu community.
"As long as there is no commercial use" (quote from Canonical's IP) we likely won't have any trouble.
The only problem that could be raised in future is our reference to the "Ubuntu Touch" project.
What we are currently shipping is exactly the same code Canonical wrote, so I don't expect any problem with this for now.
If things will change in future, we can simply rename our project as "UBports Touch" or "UBports OS". I don't see such pressure for changing this yet - just my opinion.
@Flohack Sure, it's in one of my earlier replies. (still WIP)
Here's how the "Donate" button might look in future OpenStore releases
Nice to see so many replies, thank you all for your help!
I'll try to keep this very brief. 
I see that moving files is somehow more important than other operations. We'll try to respect this evidence.
There will be improvements for the user interface, we want to be consistent with Suru specs as much as possible.
However there could be some exceptions, since a File Manager allows an high number of advanced features.
Our keyword here is probably "predictability" rather than "consistency".
In any case, we'll wave back to the forum once we have our first mockups.
We want to keep things as transparent as possible
I’m glad you mentioned "checking downloaded files" or "delete [files] when space is tight". We were expecting similar replies, and we’ve got a confirmation of how relevant is making such actions easier to perform.
SD card access: we'll probably allow it. According to the consensus we had at the App Devs meeting, there's no reason to prevent this.
Tabs: many of your replies concern this. This is for sure on our To-Do list. Implementation is still TBD.
Search: Yes, it's on the list. 
Scripts: This is an interesting option for the future, however it’s a feature that needs to be wisely designed. I think we’ll keep it in consideration for a mid term.
@Ads20000 A month ago, when I wrote it, many things were still unclear.
There were less people involved on the project, much less interest from the community, and the future of UT (and yunit) was much uncertain. During the last month, many people (even ex Canonical developers) jumped in, and many things got sort out. Also, the hype within the community increased a lot.
If you ask me what I think about convergence, I still think that it shouldn't be the first priority, since what has been left by Canonical still requires a lot of work. I still have some doubt that one single shell (which relies on many technologies written exclusively for Ubuntu Touch - e.g. the app confinement story, in particular) could satisfy the needs of both phones and desktops.
The question I ask myself a month ago was: could we expect people will still have interest on Unity 8 e.g. in an year? My answer now is that we can still put some effort on convergence, since now more people are involved on both projects, and keep everything alive.
Money and donations surely help, but I suspect there's still some trade-off. If you can't get developers to work on other parts of the platform too, it's hard to get things done. However this is not the case anymore
@bq4.5 No problem, we still have to improve the way we provide such information to the users.
For now, I'm leaving here a reference to some useful guide in our wiki - it could be useful for other people as well
Thank you again, please mind to report anything else you think is unexpected. We really need feedbacks from our community.
@demokrit, right!
We probably need anyway to get in touch with Canonical. There are interfaces for Ubuntu Personal/Touch, but I'm not sure they'll be supported in future. Their plan was to deprecate the transitional interfaces for content access, but I guess now they will be the only interfaces used on desktops.
For the confinement, the problem is not to run Snap, but running Snap with all the security enhancements. AppArmor itself is not a problem, but adding the module in the Android kernel might be (for what I understand of all that magic @mariogrip & co. usually do behind the scenes).
Click and Snaps are a bit different but, overall, yes, they are meant to solve the same problem.
Any opinion is welcomed here. Don't think I'm an expert here, I just know how to write some code -
mostly by mistake
@CyberAly There is no particular issue in building an OS upon what they have created, like ElementaryOS or Linux Mint did (well, in the LM case there have been a few).
But we can't use their name to promote ourselves. That's set in stone in their policies.
The most we can bring the Ubuntu name back is to keep that "ub-" prefix. Any usage of "ubuntu" or "-buntu" suffix is strictly forbidden. Using a "u-" prefix is not explicitly forbidden, but Canonical has already moved actions against such usage in the past.
It could be possible to ask Canonical to make "Ubports OS" an official flavour, but I can't see any real advantage in doing this. UBports would probably have to accept certain restrictions (e.g. in governance, I suspect), just for using the "Ubuntu" name. It is not worth, in my opinion.
UBports has already had a discrete coverage on the internet, so I don't believe they should completely wipe their current name away, at least for what concerns their team.
However - and I think it's a shared feeling here - the OS should really get its own brand and identity in future. To clarify my previous words, in case of emergency "UBports OS/Touch" could still be a valid fallback solution.
@Mitu - Yes, we're about to move the 'Open' button alongside "Remove" or "Update". I posted a screenshot a few weeks ago about a proposal for redesigning the "App Details" page (don't mind the slightly darker bg on that row, it wasn't meant to be there)
About the page scrolling from bottom, again yes. I'm going to get rid of that component, as we'll probably move the page into the regular PageStack,
Hey, sure! We might decide to use a "[Design]" prefix for the topic title, in the meantime.
I took some time to explore the different proposal. I have built up some screenshot, we might have interesting alternatives to the current design indeed.
Here's the current OpenStore, as it appears on our phones.
This is your first proposal with hamburger menu. To be fair, it looks a bit strange to me to split the navigation and the installed apps in that way. But I guess you already knew that 
Here's your second proposal with header sections only, as I understand it. (asking confirmation)
I wanted to push the limit a bit more further, and try some alternative solution. I came with three different proposals, but there is still some room for other permutations.
The first one is just the store as-is now, with a smaller bottom navigation, and a different style for header and highlighted app.
In the second one, I removed those carousels, and I collapsed them into ListItems. The result seems interesting (at least for me)
In the third one, I removed the bottom navigation. Search is now into the header, and the other destinations (categories and installed apps) are ListItems now.
They look a bit iOS-ish, it's true. But the second one looks a bit interesting and promising. We could try to add further highlighted apps, and see if mixing my second and third proposal might eventually work
On a sidenote, we indeed haven't done our best yet to provide all the information about our needs for UX.
The website is currently going to be refreshed, so we'd ask you to stay tuned for further updates
As you all properly pointed out, one of first goals is to provide consistency. Or, at an higher level, coherence.
At the moment we're approaching a transition from Ubuntu Vivid to Xenial, and we will be tied to a different toolkit (QtQuick Controls 2, shortly QQC2[1]).
Our effort is to port the Suru design to QQC2; in this regard, we're creating a new style for the components. Here's a very early video, the style is based on Vanilla Design[2].
https://www.youtube.com/watch?v=0ahCT7yqr08&feature=youtu.be
With the new toolkit, which offers less control on how components behave, and all the features that convergence brings, including the ability to run apps that hasn't been designed for Ubuntu Touch, we can expect some obstacle in fully implement the current set of specifications.
Our hope is that it could turn in an opportunity to refresh our Suru specifications.
The full documentation for the current Suru design is not available or, in some parts, outdated (mid-2013, when Suru was still using those odd gradients).
The same documentation available on docs.ubuntu.com has never been completed during the last four years.
In the meantime, we have seen the raise of new UX trends, one of the controversial components (the bottom navigation) has been officially adopted by the Material guidelines, and Canonical decided to drop its Ayatana project (i.e. Unity 7) and adopt the GNOME 3 HIG.
What we need is help and guidance through these multiple inputs, in order to fix some of the current issues in usability, and eventually validate the design of new UI components. In a longer term, we might want to support an effort to revisit the current design guidelines.
I saw you've been interested by the recent changes in clock-app.
Feel free to open a new issue, or join existing discussions at: https://github.com/ubports/clock-app/issues
Thank you again!
======
[1] https://doc.qt.io/qt-5/qtquickcontrols2-index.html
[2] https://github.com/ubuntudesign/vanilla-design
That's a great proposal, we'd like to follow up with some plan.
Documentation is expected to be available soon on docs.ubports.com, once the transition from the old wiki to ReadTheDocs will be concluded.
For the moment being, it's available at https://github.com/ubports/phone-docs/blob/master/en/apps/design/index.md
It's fully browseable through GitHub.
One of biggest concerns is how to coordinate the two concurrent efforts (by developers, and UX designers), without compromising the quality of the process.
While we want to avoid awful visuals like red scrollbars
or mixed typography [1], we need to ensure that coordination between developers and designers can be smooth as possible. I'd suggest to avoid any cross-posting of pull requests both on GitHub and this forum, since it might get easily insane to keep the discussion on the right track.
What we could do (and it's welcome):
Promote the participation of developers on this forum, and enable a channel where app maintainers and designers can discuss their ideas with no friction. This should work as a place where we can explore multiple solutions and proposals, without bloating GitHub with informal discussions.
Promote the participation of designers on GitHub. Feedbacks and bug report for UI/UX questions are welcome in the bug tracker, and we're currently planning to mark any existing design-related issue with an 'UX' label for better discoverability. We might also offer a repository where we could store all the official mockups and existing documentation, with a full history of changes.
Ask code contributors to answer a few short questions whenever they prepare a new pull request. This would work as a first filter for "unconfirmed" changes, and is what the 'unity8' project used to do back at the time. An example of the questions can be found at [2].
I already see some reply by designers, and we absolutely appreciate it.
I'd like to ask all the designers on the forum to let us know if they're interested in the creation of this new group. If so, please feel free to reply here.
I'd also like to survey your familiarity with the typical tools used in open source projects and, in particular, GitHub.
Most of the developent happens there, and many design teams (including GNOME and Canonical) currently use the platform for design discussions with a discrete success[3].
Knowing your preferences on this would help us to support you with the most effective workflow.
As a final note, I'll try to get in touch with Canonical to see if we can get some documentation for the various UT projects, since not all the docs have been publicly disclosed during the last years.
Thanks for your posts, and in particular @Mitu for the proposal.
=======
[1] An interesting insight on early design approach in Microsoft
https://medium.com/microsoft-design/a-brief-history-of-design-8641bd186e00
[2] A current example of a merge proposal / pull request: https://code.launchpad.net/~josharenson/unity8/dashboard-manager/+merge/319522
The list of questions included at the link above:
* Are there any related MPs required for this MP to build / function as expected? Please list.
* Did you perform an exploratory manual test run of your code change and any related functionality?
* If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
* If you changed the UI, has there been a design review?
[3] As a reference, both GNOME and Canonical coordinate their design processes on GitHub. The topic has been nicely disclosed here:
https://design.canonical.com/2017/04/designing-in-the-open/
@Flohack Sure, it's in one of my earlier replies. (still WIP)
Here's how the "Donate" button might look in future OpenStore releases
Thanks for your replies!
I chose the 'heart' symbol since it was the nearest symbol in terms of kindness and appreciation. I like @vadrian89 's idea of using a gift box as icon; the bad news is that our Suru icons set does not provide the icon.
If someone wants to contribute and create for us an icon that matches the Suru specs, the contribution would be very appreciated.
As an alternative to the 'gift box' and the 'heart', we could still use the currency symbol as proposed by @doniks . QML provides an easy way to get the currency symbol according to user's locale. That way we can solve any ambiguity related to its usage.
I missed this topic, but I see @Flohack has already provided solid arguments.
elementaryOS is backed by "elementary LLC" which likely enables them to handle money on a solid legal base. I gave a quick look at "Houston", the app store back end used by elementary, and it seems they only support a single service, called Stripe. I haven't tested personally, but what I see is that developers might likely have to create a Stripe account in order to receive donations.
This might add a further consideration: choosing a single service implies excluding others.
We could offer e.g. PayPal support, but I'm mostly sure our developers might (legitimately) ask to support Patreon, Liberapay, Bitcoins, etc. Not to mention potential existing service bans in specific countries. It might end up in a huge amount of work, for an app store service that merely counts 400 apps and has not fully shaped yet.
What we did in OpenStore, but we still need to expose it to the client app, is to let developers to specify a link of their choice for donations. This already enabled developers to received donations through the OpenStore web UI - e.g. Dekko.
I'm in charge to get this done in the client app. Despite my expectations, adding a single button to an existing hiearchy of informations is not so trivial; as a consequence, it might take a while before we could roll this out in a new update, since we have to redefine how we provide other metadata.
I'm currently redesigning the "Package Details" page in the OpenStore client, and the idea is to ensure that our "Donate" button would always be placed above the fold, in order to ensure that potential donors would not miss the opportunity to support the work of developers and contributors.
Here's how the "Donate" button might look in future OpenStore releases
Feedback welcomed!
This is part of the draft I was working on:
1 ) Allowing apps to access specific sub-folders in XDG user's paths. That would be possible by adding 4 new AppArmor permissions, for a total of 16 lines added.
2 ) Changing the path where core apps import ContentHub files.
The current situation is:
I would propose to change them as follow:
The major effects are:
Issue you mentioned at 1) would also be solved in the 80~90% of cases. For instance:
I haven't found the time for further validations, as I planned to check how these policies would work with ~20 different apps currently available on OpenStore.
Anyway, it might be worth to add them to this discussion in order to have more proposals, and try to see the overall picture
As part of the File Manager refactoring, I've been working on a draft for Content Sharing back in August. The main problem was that users were expecting File Manager to load any content type, rather than exporting it through ContentHub; then, I started a comparison with the Android platform.
TL;DR
What I found by far was:
My wild guessing for your questions
That seems hard to achieve in the way we would expect on a desktop - I guess - for the reasons explained above. The confinement rules and the non-standard way content are handled does not seem to integrate with standard tools.
This could be achieve already:
2.1) Apps like gallery-app could prompt for a specific action when there's a transfer on-going
2.2) A single click package could ship more than an application registered to ContentHub.
2.3) For specific "well-known" actions implemented by core-apps, third party applications could rely on UrlHandler. For instance, this is what we're planning to do with the new File Manager, when we will add the built-in text editor.
When I still was the DocViewer maintainer, I've been asking to ContentHub devs to expose the original path of an imported file, in order to prevent this (in a sane way).
Ok, so is the problem only related to the icon shown in the header? If so, we can remove it, and keep just the text.
Yes, I have some files due to my contributions on the Document Viewer. I'm not sure whether I can publish it on internet or not, since it's internal documentation (and in some part it was still WIP).
Actually, we (as UBports) might want to ask - or try to - Canonical if they can give us all the design stuff they have been working on, and add them to docs.ubports.com
Yes, the question is that we provide the same functionality as a sidebar on tablets and desktops, through an hamburger menu at the leftmost position, therefore the problem. I've been thinking to some solution: we will push an update on OpenStore in order to see if that might work.
That's on our to-do list. It's not planned for v. 0.5 though, but we expect to make it available within two months. Specifically, we have planned an image viewer, a media player (i.e. video + music), and a text editor.