See turbolinks 5 presentation for how to do this https://www.youtube.com/watch?v=SWEts0rlezA
Start with using mobile views everywhere and improving these.
- Login (store credentials indefinitely so I don't have to log in again)
- Error/refresh page
- Rating according to modern practices
- Main navigation page?
- Hamburger menu pop-up as shown in the presentation?
- Todo's to make them more usable?
We hire one person for this:
- Does both iOS, Android, and mobile views
- Reports to the frontend lead
- Most time spent improving the mobile views
We should approach all the authors of the native apps https://about.gitlab.com/applications/ for this job.
Based on discussion in Slack, there are two main options here:
Turbolinks 5 webview app
- Easy to build
- Updates automatically alongside our Rails app
- Forces us to improve our responsive site
- Requires updating to Turbolinks 5 which had a lot of breaking changes
- Poor user experience in many cases, can be very frustrating to use, takes up a lot of battery, non-native feel (see: Basecamp app)
- Requires supporting a special "format" from the Rails app for sending the site to the iOS and Android app
- Requires constantly checking the webview app to make sure updates to the website don't break the app
Native apps for iOS and Android
- Forces us to improve our API coverage and documentation, making it potentially a better experience for devs interested in building experiences based on/around GitLab
- Arguably faster to develop once you take into consideration all the weird bugs that come with a webview app (or arguably slower, this is up for debate)
- The API should be more stable than the webview, leading to less breakage
- More difficult to build
- Must be built from scratch
- Will lag behind GitLab releases with regards to feature support
See conversation in core team channel if you have access https://gitlab.slack.com/archives/core/p1466006566000037
I know that a web view experience isn't optimal.
But GitLab has a lot of screens, a native mobile app would take two teams to make and slow down development.
The only thing I want is something that doesn't retake me to log in the whole time. And we need great mobile views anyway for people not using the app. That is what the mobile developer will spend the majority of its time on.
I completely disagree that we should do a webview. It has always 100% of the time turned into a complete nightmare situation. Making a native app in the language of choice is always easier, faster to develop, faster to run. Even though the idea of writing code twice seems tedious.
Writing a native app has that bad rep of being really really hard. But it is really not hard at all. In all ways it is easier. XCode is drag and drop. This is something I have experience in. I've written (in teams) many many (10+) webview apps, many many (10+) native iOS apps in swift and obj-c, and a few (3 or so) native android apps in java and every single time the webview app turned out to be much much more work than the native ones.
I urge you to check out the native iOS app I started. I've spent less than 3 hours on this (in my spare time) and I was able to get projects/issues/comments all read only with simple markdown highlighting.
If you think we have problems with large MR's now wait until it shows in a webview.
If this whole site is being made beautifully responsive and there aren't any deeply concerning performance issues (the toughest views are going to be the big lists of issues and diff views etc) then it makes a whole world of sense to build this with webviews. But at that point, why do we want an app available on the app store that is a replica of the responsive web application?
I agree with @sytses. We should not spare our attention by building 2 applications (web and native) at same time. I think instead we should primarily focus on web part.
People share link to GitLab project/issue/comment via chat, twitter, email etc. I want people to visit those link without any application installed and still get usable interface with valuable information.
@dzaporozhets This is a road I've been down a lot. Just remember, just because it is a webview does not mean that you simply insert your already created application. Many have been down this path. You will either spend the time, desperately trying to get your webview app to be usable, and sacrificing gitlab.com to it/forking it and having to keep it up to date. 2 version of code that are now out of date and drastically different and both need updating. You now have 2 sources of code no matter how you put it.
Or you write the app the way it was meant to be written, so it performs well when someone opens a big diff. Same 2 sources except the problems are solvable.
@jschatz1 has won me over to the application using native code. Hybrids inherently have a low bar in terms quality and I think with a product like GitLab, if it's going to release a native app, it has to meet that native standard of quality. (Libs like crosswalk help this, but you will 100% end up maintaining a bloated application when this begins)
Saying that, I still think the native application has to offer some sort of enhanced UX for mobile users, I don't see the value of 'duplicating' the responsive view of the web application as it is right there in the browser, this could be bookmarked and added to the home screen. This then requires a full discussion and redesign based on the needs of mobile git service users?
I still think we should continue to focus on getting the web app super mobile friendly as the issues come in.
I just had a great conversation with @dzaporozhets.
We agreed that if this is a super simple implementation as it promises to be. And if it involves writing minimal code 1 time and the whole thing works great from the git-go then there is no reason we shouldn't do this. Fanatastic!
If for some reason it involves a lot of work where we have to modify each individual view and every time that we modify something on the site, if we have to make a change to the app to maintain it properly then we should do it right and make a native app in it's native language.
Hey chaps :)
I think it's really cool GitLab wants to build this, I wanted to share with you some thoughts I've had since developing Git Trident.
Since v1.5 I've included some Analytics to understand how users are using Trident. It wasn't how I expected!
The majority of usage seems to be around code browsing (the top usage category) and code detail (inspecting a code file). This is actually the least developed feature of the App, and Trident does it kinda poorly (the syntax highlighting is terrible!), and there's little information around current commit hash for each file.
The second top usage is 'active' which is when the app is brought to the foreground, to me this might suggest people are opening and closing Trident over the course of the day as a quick glance of what's happening.
Secondly there's listing Merge Requests and Issues which is popular, though suggesting Merge Requests are more important.
Surprisingly, going into a Merge Request or Issue, creating issues, closing issues, is not used often! (I spent the majority of my time in these features, and they are hardly used). My initial idea was to build Trident as a place to discuss issues etc, but that's not how people are using the App.
Overall, these findings to me suggest I should be optimising the App for better code browsing, and improving quick informational displays about the project (I have been thinking about developing a widget for the Notifications screen that shows open Merge requests, Issues assigned to you etc, and improving notifications for iOS 10).
If GitLab does decide to build its own App, please keep improving the API so indie devs like myself can make products on your platform
@sytses Here's what I'd love to do with an improved API:
I'de like to show per file last commit message, date and SHA with listing Repository Tree. (http://docs.gitlab.com/ce/api/repositories.html#list-repository-tree).
Dashboard & Notifications
I'de like to show a users dashboard, for all projects they are participating and subscribed to. It would be great if the events returned from the API were similar (but expanded) versions for the project event API. The equivalent GitHub API would be this: https://developer.github.com/v3/activity/events/#list-events-that-a-user-has-received
It would be awesome if this API could be either optimised for Polling or (now this would be incredible - Webhook able)? Polling GitHub as been a real PITA! My little notifications server is already struggling with the users it has now >.<
I understand there is a GitLab atom feed XML that can do this, but it wouldn't be a REST API with all the info I'd need to make it a good experience :(
I opened an Issue related to this, but having thought about the problem more, I'm not sure an API for Todo's would give the type of events I need :( #18450
Merge Request & Issue Timeline
I'm presently rebuilding (yet again!) the Issues and Merge Requests conversations history to be much faster (using a single WebView for the entire conversation history). GitHub recently introduced an API that's going to help with this, it's a complete single Timeline for all the events in the Issue or Pull Request. https://developer.github.com/v3/issues/timeline/
GitLabs Notes API for Issues and Merge Requests gives Markdown. But what I'm really trying to do is render the entire timeline, to do that I need information about all the events, comments on files (for code review). Essentially, a GitLab equivalent to the Timeline API would be fantastic?
This would be a great API addition for me! Being able to find an issue/merge request - really would love to do that with GitLab.