[DO NOT MERGE] Provider base frontend, backend, style and some TP

[txels]

Story: http://txels.tpondemand.com/entity/273 initially but I got excited and added a few more things:

• Angular initial code to support provider setup
• Styling
• Some initial client code for TP (I may fork that as a separate project)

So now, when you complete github-oauth, you go to the github configuration page.

---

Just to let you know I'm working on this. It depends heavily on the teams PR (https://github.com/pretenders/ployst/pull/38) being merged though. I'll recreate this one to develop afterwards.

See what you think of my approach to declaring providers, metadata etc.

Additionally I have been playing much more on styling and here (2nd commit) I'm going for a UI approach based on sidebar menu and submenu revealing from the right (later on I'd love to add a little animation there). Tell me what you think, I was planning to make this the base for the UI look and feel for the whole app.

Should look like this:

[alexcouper]

I really like the far left menu bar, but I don't so much like the second one because I feel it takes up too much space on the screen.

I wonder whether we could have them appear as subitems beneath the relevant menu heading in the left hand bar?

One issue I have with tp3's design is that because they place visual priority on the menu bar, status bar, selected cards and filters, the "working window" becomes very small. I think we should limit ourselves to one such bar, if any.

[txels]

Let me explain my rationale/vision behind this. Feel free to argue against my points.

I have a personal grievance against many sites and apps in the web, where most of us are browsing using wide horizontal screens but most of the web is designed still around narrow display and lots of vertical scrolling. People using ployst are going to be developers using screens with much more horizontal than vertical space, and I want to avoid scrolling as much as possible.

For that reason, I am trying to get rid of any items that take up vertical space once within the app: there will be no headers, no footers, all navigational and contextual elements are going to be on the sides. Data that we need to present as central content shouldn't be that wide anyway as it would hinder readability. There will be usable space on the sides that we should make good use of.

Even as I'm typing this I'm looking at this github page and there is lots of empty white space to my right and left (about 50% of wasted screen space), and all the navigational elements are gone. In order to get to some meaningful place outside of this page I'm going to have to scroll up.

That said, my intention is not to make these sidebars so wide. My idea was that once the secondary menu opens up, the first one should collapse to a state where it only shows icons for the main menu options.

Something like this (with larger icons on the collapsed menu):

...and we won't probably have more than 2 levels of depth.

In particular I want to avoid sub-items in the main bar as the potential for growing out of space and requiring scrolling in the nav is bigger (unless we recur to "accordion" collapsing which can be irritating as clickable targets move - e.g. if the menu you are collapsing has considerably more options than the one you are opening, everything scrolls up and your target appears higher than where you clicked).

The main reason why I haven't been able to do the collapsing main menu so far (and which also makes the subitem approach unreasonably hard) is because that menu is out of angular-land and I wanted to avoid mixing up jquery and angular - so I need to work a bit on making sure the main menu is within the angular app.

Opinions, counter-arguments?

(BTW I think we sould not show the copyright notice once logged in)

[alexcouper]

I'm fine with that approach, perhaps we should create a UI doc in the repo to detail the philosophy behind the UI.

Certainly making the first menu shrink down to icon-width will remove my concern of the page being eaten away. And as long as we don't then hinder the "main area" with fixed footers/headers then I'm very happy with this approach.

However, I see no compelling reason why we should ban footers and headers outright. That is, if there is something that we want at the bottom of the "main area" then that is fine - I just wouldn't want that to be an overlaid "gutter". Not sure if I'm making sense. ie. a github style footer I'm OK with (scroll down to get to it), but I'm not a fan of a tp3-style one (always shown).

[txels]

Hey I've managed to do what I wanted: get the main menu into angular, and do a "collapsed" sidebar. I will now close this PR and reopen to develop.