UI Proposal

[ramijames]

I really love the idea of having a single repository locally which I can use to manage all the available plugins for Sketch.

I thought I'd contribute some of my ideas in a visual form here on Github with you guys. Created in Sketch, of course :)

Basically what I'd like to propose are a few key features:

1. Auto-update which allows the user to control if things are updated or not
2. Preview the readme.md in the app

[ramijames]

I've gotten some feedback and users are interested in the UI being more in sync with Sketch and the standard HIG from Apple. I've updated my sketch accordingly.

[shahruz]

Hey, this is an excellent proposal!

Before committing to a specific design, I would like to get a better sense of the data available (as being discussed in #6 and #15). Once that's a bit more realized, I think it makes sense to use your second version here as a good starting point!

[timuric]

I would like to add that it would be necessary to take in to account updates of the existing plugins. Probably there is a need for two tabs with updates/installed and discover page :)

[shahruz]

Yes, agreed.

Maybe: A 'Discover' page which only shows the plugins you don't have installed. Can be sorted by Name or # of Stars.

An 'Installed' page which shows all plugins you do have installed. Plugins with available update at the top, then the remaining sorted by name?

[timuric]

@shahruz Maybe an appstore like window, with 2 tabs only "Discover" and "Installed" with a search bar on the side. Such interface would be easily extensible for new features as well as be friendly to new users since they already be accustomed to it :)

[ramijames]

I really love the idea of an "app store" like UI. It's a bit more complex but there are a lot of advantages like discoverability, scalability, clear categories, etc.

I'll go over the wireframes and post when I get a chance.

[ramijames]

We would have to place a default image and this is really the core of my hesitation with building out an interface which is like the App Store. There are many additional complications which we don’t run into with the original UI I proposed above. Such as:

1. Requiring plugin authors to provide an image of a specific size
2. How to present the main “discovery page” (equivalent of “featured” in the App Store). Who selects what is featured (in the App Store, apple does)? How do you order plugins on a page like that? How is this better than sorting by most stars in a vertical listing?
3. Separating out “Installed” to a new section makes sure the user sees what he has installed and what has been updated/needs updating. The question we should ask ourselves: is this necessary? If not, then what’s the purpose?

Basically, after running through a series of wireframes, I do not think that an “App Store” variant is the correct UI for solving this problem.

We need a UI which solves two key workflows:

1. Discover useful plugins and install them easily
2. Manage updates on installed items

I propose altering my original UI to include a top-level filter which shows "all available / currently installed”. This will allow the end users to find new plugins and also manage their currently installed set.

[timuric]

@ramijames you made great work. Regarding the appstore, I meant only navigation, the content is obviously different. The difference between your sketch and appstore would be basically the placement of "All plugins" and "installed". Having switch like in appstore has following advantages:

1. Section like in appstore will allow to differ "Installed" and "All plugins" views, while in your version it there will be necessary to keep the same layout in both sections.
2. Navigation would be familiar to the user
3. Adding with new sections would be straightforward.

And there will be no need to change all your design to achieve this, you can simply locate the "All plugins" and "Installed" switch in the top header of the window :)

[florianbuerger]

I really like all your ideas about the UI design and discovery but maybe we should focus on the core functionality (installing/updating plugins) for now and consider the much nicer UI for future versions.

[timuric]

@florianbuerger Agree that functionality is the most important at this point. However how would you consider accommodating updates feature in the UI? Maybe something like this?

This is not deviating from existing UI much, and will require minimum effort.

[ramijames]

I totally agree that basic functionality takes priority over UI design and discovery. It's all that I can really supply for the project, so I'm starting a conversation which can hopefully have some positive impact later on.

Here is an update with the App Store tab structure on top. I've also added the description back into the list and have added a small indicator showing installed status if the plugin is installed.

[shahruz]

This is all really great.

Assuming you've all seen the latest version that's on GitHub currently, what would you suggest is important that's left for a "beta" release within the next couple days? I've been working on this UI update, but I wonder if there's something more pressing/important that I'm missing.

[timuric]

@shahruz I think right now the core functionality is the biggest necessity. At the moment there are not so many plugins yet, I assume most users need simply updates and easier installation process. So making just these two things work would be already enough for most users. As the user base would be increasing there will plenty feedback and ideas :)

[shahruz]

@timuric The version currently on GitHub has this functionality (at least it works on the two computers I've been testing on). Installing + automatic updating. Have you had a chance to try it out?

[timuric]

@shahruz oh really nice! So it already shows updates based on json file versioning?

[shahruz]

Ah, no. That system isn't quite in place yet. Currently, if you have a plugin installed, it will check to see if there have been any updates pushed to it on GitHub. If so, it'll automatically update.

I think @ramijames has the right idea in his mock of allowing users to opt out of auto-updating, but I wouldn't consider that a core feature for a shippable beta.

[timuric]

@shahruz Yep, auto updates are good, many users of my plugin are altering the contents of it, would be bad if they would suddenly loose their modifications.

Would be nice to have push notifications for updates, since users probably would not be checking the application often. However this probably could hold for a while, maybe we could solve it with some shell startup script, or it is too complex for now?

[shahruz]

@timuric Yes, I've been thinking about this in a couple ways.

• For local modifications, I'm exploring ways to allow the user to keep those, and only perform the diffs on Git. Of course, this is a really complex problem, and there's absolutely no guarantee that things won't break. I don't think I'll be able to come up with a reliable solution for this in the short term, outside of allowing the user to simply disable auto-updates. (Simple modifications like Keyboard shortcuts will be easy to isolate though, which is why I want to tackle that sooner.)
• Push notifications is interesting as well. I've been thinking about how to make the app something that people can leave running without having to see it active in their dock at all times, so that we can periodically check for updates and do all push notifications locally (it'd be a hassle for an open source project to do remote notifications IMO). My best idea so far for this is to have a separate process that runs in the background always (unless the user opts out), that doesn't require the app to be 'open'. This process would send out push notifications when there is an update available, and clicking that notification will pop open the main app to the appropriate plugin. This isn't all that complex, but something that will take a few days of development to get right.

[timuric]

@shahruz Maybe worth asking bohemian coding if they could include a startup scrupt into sketch that will to check for updates :D

[shahruz]

@timuric Not entirely sure if that's even possible with sandboxing!

Here's a screenshot of what we have now, btw. Realized I haven't updated the readme in a few days.

[timuric]

@shahruz Btw I noticed that stars count are wrong for some reason.

it is 1199 in the here (built from latest source) http://cl.ly/ViKN Whilst 1202 here https://github.com/timuric/Content-generator-sketch-plugin

[shahruz]

GitHub has a rate limit (60 requests per hour), so I'm caching the star counts locally. I want to eventually modify this so that each user isn't hitting the GitHub API on their own, but rather pulling from one serverside source that can be updated more frequently..

[ghost]

Is this still being decided on? I'd like to help out if I can.