search

scout-app / scout-app

Scout-App - The simplest Sass processor
http://scout-app.io
MIT License
693 stars 101 forks source link

Scout App 2 #186

Closed zdennis closed 8 years ago

zdennis commented 9 years ago

Despite my lack of updating Scout it continues to be useful for people. This is a great motivation for updating Scout and it inspires me to want to improve Scout. When @mejiaj mentioned on #185 the idea of requesting help from the community of designers for progressing Scout, it hit me, that I should have asked for help a long time ago.

Request for help

ScoutApp needs design :heart:. I am not a designer. The last two designers that were working on ScoutApp got busy with life. This has been been a obstacle for progressing ScoutApp. Help is needed in all aspects of design: visual design, UX, etc.

I am not a Windows person. There are some OS integrations that I'd love to incorporate into Scout. If anyone knows any Windows devs interested in helping I'd love to take advantage of that to ensure that the Windows user-base gets the love and attention they deserve.

Feature requests or pain points. If you have them please comment on this issue. I don't pretend to know how everything should work and some of my ideas listed below may not be good. If that's the case please tell me. I want to hear that. I'm more interested in a better ScoutApp then getting my ideas in.

If anything else feel free to share.

Goal of Scout

Scout is a cross-platform app that delivers the power of Sass & Compass into the hands of web designers.

High Level Feature Descriptions

A very basic reference of whats defined here are found in the UI mockups of: http://www.continuousthinking.com/2012/11/21/iteration-1-redesigning-scout-app.html . Please ignore the actual design used there. It’s just to provide a reference for some of the features in how I’m thinking about them.

ScoutApp needs to support the concept of projects. Projects need to be added, edited, archived (more on this later), and deleted.

A user should be able to configure a project’s simple properties. All properties will be stored in a Ruby configuration file on disk.

A user should be able to configure a project by advanced means, aka editing the raw source of the Ruby configuration file (thru the ScoutApp UI). This is to support customizations for advanced users.

A user should be able to define the libraries (ruby gems) they want to for their project. This is essentially a front-end for modifying a Gemfile. All library definitions will be stored in a Gemfile on disk for that project.

A user should be able to configure the libraries thru advanced means, aka editing the Gemfile directly thru the ScoutApp UI. This is to support designers copying and pasting installation instructions from web-sites of Compass and Sass libraries.

A user should be able to ask Scout App to update it’s libraries. For example, if there is a new version of html5-boilerplate, I should be able to update the version in my project’s configuration and then tell Scout to “Update”.

A user should be able to access the log of the Compass/Sass compilation for a project. This will be a live stream of compilation output.

A user should be able to update their versions of Compass/Sass for all of ScoutApp. If they want to use specific versions on a per-project basis they can override those there.

I'd like there to a scout project file (e.g. directory on OSX, not sure about Windows) that contains all project-specific configuration stored in the user’s directory. This is to enable adding scout configurations to version control or sharing with other users. It also means that a user could remove a project from Scout and then later double-click on the scout project file to add it back to Scout.

A user should be able to start and stop compass/sass compilation for a project. Users should be able to intuitively know thru the interface when a project is “watching” for file changes or not.

There needs to be a way to communicate compilation updates to the user (either in the app or thru native OS notifications, etc). This is so the user can do something about an error and knows when it has been fixed.

Projects need to support archiving. This is to support the designer that has a lot of projects. They may want to archive those they’re not working on (but not delete them).

Over all, Scout is intended to be less intelligent about project’s in particular. It will know how to write out files that Compass/Sass understand (like Ruby configurations) to keep Scout’s internals simpler, and to allow for greater flexibility in how a user may interact with compass/sass.

Previous Attempts at a Updating ScoutApp

mejiaj commented 9 years ago

@zdennis Hey thanks for doing this, your work is much appreciated! :smile:

As a designer I'm happy to help out a product I've used for a long time. What about the possibility of using something like libsass with a fallback pointing to a ruby install? It might be missing a few features like sass maps, but it seems like a good bet for the future.

As someone who works on a lot of SCSS/CSS I like the option of disabling compass and just running with plain SCSS with autoprefixer.

Building on the project status/state idea it might make more sense to set a watch all projects by default and maybe a toggle for a feature to only watch 1 project at a time for performance.

I love the idea of a ScoutApp settings file, this would be a killer feature for teams! Can't wait to get home and work on some ideas/wireframes. :bowtie:

TheJaredWilcurt commented 9 years ago

@zdennis I looked over the older UI mockups and created a quick YouTube video discussing ideas based on that.

There's a link to the demo shown there in the video description.

@mejiaj I previously recommended Node-Webkit as an alternative to Adobe Air for a cross platform foundation to build the new Scout-App around. With it you can use any node_modules that you normally could with Node.JS and NPM. They just get packaged together with the rest of the files when it's time for distribution. Another plus to Node-Webkit is that it can output executables for Windows, Mac, AND Linux. Adobe AIR stopped supporting Linux in 2011.

This fits in nicely with your Libsass/ruby fallback proposal. There are two popular sass node modules, one that runs libsass, and one that relies on an installed copy of Ruby. I think it would be nice to have both so people who don't care about compass can get the speed of libsass, meanwhile it doesn't cut off those who want the full power of what Sass has been built up to.

This also sets Scout apart from the 10 or so other Sass GUI's that are out there which only offer one or the other. Scout could be the first GUI to offer Ruby Sass and LibSass. It may even be possible to edit the grunt-contrib-sass (ruby version) to point to a portable copy of Ruby that is embedded into Scout, meaning Windows/Linux users wouldn't have to install Ruby (Ruby is pre-installed on OSX). I'm not sure if an actual installation is needed (with environment variables and registry edits and whatever), or if it merely needs the files in the right place. In any case the grunt-contrib-sass is all just javascript text files for the the most part, so if it doesn't require an actual installation then it shouldn't be that difficult to get set up. This needs to be researched though if Scout uses Node-Webkit.

mejiaj commented 9 years ago

@TheJaredWilcurt Yeah, node-webkit seems like a great option for a cross-platform scout-app. Especially if we can package modules from NPM. This would allow us to even go as far as including a font-icon creator from a folder of SVG's, right? That would be sick. Maybe we could even have a little package manager...

I saw your suggestions/critique video on youtube and I agreed with a lot of stuff. I think it's critical that we make this as easy to use as possible, but with the option to customize. Though, I can't see the benefit to beginners or advanced users in having that 100x100 grid layout. I find the minimized view interesting. The one issue with it is the error state. The extra step in clicking and seeing the error seems potentially annoying. Here's how I picture the flow (please correct me if I'm wrong):

Use wrong SCSS include > error notification popup > click takes me to minimized scout-app > click again to see error.

My Take

Some ideas I've been working on feel free to critique/comment:

Landing Page

Plus to add folder. Eye is a 'Watch All Projects' button. This would be great for people to just turn it on and jump around on projects. Settings takes you to global settings if you don't have any projects in. About/Info button gives you app info and ability to update (button would be highlighted if update is available). The archive project was left out because it's fairly easy to zip a folder, but if you guys feel it's crucial we can add it.

Global Settings (simple)

Standard stuff, this is where you setup the defaults if you want to. I think the frameworks section needs more work to make it easier to see if the version is up-to-date or not.

Global Settings (advanced)

You can specify auto-prefixer settings and directories (when you add a project).

Project Settings (simple)

The project background on the sidebar gets highlighted. Should've made it more obvious. Advanced option would let you specify whether or not you want the config.rb and autoprefixer stuff. Maybe we could move mixin/framework management to the advanced mode?

Watching a Project

Status bar on the left of the project title in green (watching and OK), gray (not watching), and red (you done goofed). Projects have directory info below the project title and you can even edit the project name if you want. I haven't seen an app that does this and I think it would be really useful. I could name my projects (Jurassic Park II DEV & Jurassic Park II QA) instead of having the same folder name with a different directory.

cdCorey commented 9 years ago

@mejiaj Nice work.

TheJaredWilcurt commented 9 years ago

Sorry I've not responded in a while. I've been working on a side project to get a new job. I just got offered the job. So my order of tasks are:

  1. Finish up Side Project (I've been working on it with two friends, should be done soon).
  2. Get UGUI up to version 1.0. This is a Node-Webkit library and framework. I'm learning a lot about Node-Webkit in the process. So I want to get this up to version 1.0 before going into actual development mode for an app in it.
  3. Scout-App 2.0! Soon. Such a busy time of year.
mejiaj commented 9 years ago

Some Updates

So I've been thinking a lot on how to make this app more intuitive and really trying to cover the essentials that front-end developers need today.

Start Screen

Controls and Content/Information are clearly separated. Controls are icons only, but they should have tooltips w/ text. Some thoughts on the settings:

I've also added a friendly welcome message to re-emphasize how easy it is to use the app.

Watch Mode

Pretty straight forward.

Settings - CSS

I really like the current setup with input/output. I'd like to see the app add the folders automatically and then let the user change output. Autoprefixer is a great tool and I think we should try to incorporate it. If this application isn't possible please let me know, but I think we should have it somehow.

Settings - Images

This setting would be optional, but I think auto image compression for PNG/JPG/GIF would be very useful.

Settings - JS

Optional as well. It would combine and minify specified JS files.

Settings - Plugins

This one is up for discussion. I know there's a lot of requests for this type of functionality. I'd like to hear your thoughts on how to best implement and manage this to come up with a more effective design. We should add some essential plugins based on popularity and then give users the option to install their own.

About

This page checks for the latest version of Scout. It also credits everyone that contributed to the development of the app.

Did I miss any features/functionality? Do you guys think this is intuitive enough? Let me know if there's anything I missed. It'd be cool if we could get a custom icon-set, so if anyone knows anyone with a solid portfolio of icons feel free to contribute.

cdCorey commented 9 years ago

@mejiaj These latest wireframes are looking pretty awesome. For me, the inability to use autoprefixer is one of the top reasons I've been looking for alternatives to Scout, so I would put incorporating that pretty high on the list. I have other software that handles compression of other assets, but combining image compression and JavaScript minification into Scout sure would simplify things.

kavillock commented 9 years ago

@zdennis any info's, it's great app, but without updates it can be old

zdennis commented 9 years ago

Hey @kavillock, yeah, I hear you. It does need to be updated. I haven't made any significant progress since last winter's conversation with @mejiaj and @TheJaredWilcurt . This project is still on my list, but it's just on the back burner for now. I wish I had better news for you right now.

One thing holding development back is time to finish updating it and building it. Out of curiosity, would the people on this thread be happy or appalled if we put up a kickstarter campaign to compensate those who would work on it (so we'd have time to make it) in exchange for getting free copies of the build?

mejiaj commented 9 years ago

I'm still here and ready to go whenever. :smiley:

@zdennis It would be a good motivator, but wouldn't that add complexity to the project? Establishing a system of compensation might be difficult.

TheJaredWilcurt commented 9 years ago

@zdennis @mejiaj

I was just talking to my friend the other day about how I had intended on helping with the new version of Scout after I finished my main side project, since it's related. I've gotten very far and learned a lot, all of which is directly applicable to Scout 2, but I still have a lot more left, which I wasn't expecting. So I'm thinking of taking a short break from it to start in on Scout.

The thing I like most about the Java/Air version is the simplicity and ease of use. It's the UX that makes me still use it after years of being out of date. There are lots of alternatives, but they're all trying too hard to do too much and failing at ease of use.

I see a lot of talk in this thread on design. We've not really come to a decision on what the design should be, but everyone's contributed lots of great ideas. So I'm not too worried about that at this point, I know with this group the design will end up good.

So I feel like my role should be to get the ball rolling. Tonight I created an NW.js project folder for Scout. My intention is that here in a day or two I'll have it up and running as a basic start for the project. I don't want to be the main guy for Scout, maybe like 5-20% will be me. But I do want us to at least start a branch and begin development. This start will just be a basic functioning version, nothing fancy. From that we can flesh out the design, layout, styles, and UX.

As far as KickStarter goes, I don't think splitting up the money would be where the added complications come in. I'd think it would be in meeting deadlines and spending time dealing with KickStarter overhead instead of spending that time on the project itself. Things like explainer video, goals/stretch goals, and rewards. That's additional time and effort that I think could be better allocated. But whatever.

Project management:

Feel free to discuss this plan of action and outline more details.

TheJaredWilcurt commented 9 years ago

Quick update. So I've made a semi-functional demo app. I still need a few days to polish it up before pushing up a branch. It's pretty basic right now, but it works, and it's a start.

TheJaredWilcurt commented 9 years ago

@zdennis @mejiaj Here is where I'm at so far.

Project (General)

I started a NW.js project for Scout-App 2. The general UI is there and looks okay, though I'd personally prefer to have the UI redesigned and be completely custom as right now it's just doing some Bootstrap stuff. But the basics are all prepared (icons, folder structure, project settings, etc.).

Node-Sass (Fail)

I tried out using Node-Sass, a Node module that would have been the engine to process sass/scss files to css. It is a JS wrapper for LibSass so that each OS can have Node run LibSass using an OS specific binding. It has a lot of good built in functionality, however couldn't do absolute paths, which makes it unusable for our purposes. So "C:\MySite\sass\" won't work but "....\MySite\sass\" would. And if the user has a project on a separate drive/partition it would not work. Node-sass is designed to be ran via command line in the users project folder, not ran from a different location pointed at it. I also toyed around with using it's CLI version, but that was a dead end as well.

SassC (Maybe)

Currently SassC has over 98% compatibility with Ruby Sass. It is a command line wrapper for LibSass. The downside for this route is we would need to keep track of SassC and compile our own native executables for each OS environment. Bare minimum we would need to maintain Ubuntu 32-bit, OSX 64-bit, and Windows 32-Bit. That should get us by and work on all systems that NW.js works on and keep Scout-App cross-platform. Currently in the testing phases with this. I'm using an already compiled copy from a SassC-Win repo for now. It's lacking a lot of functionality that node-sass has, so I'll need to add that in by hand with Node. I'm not worried about that, shouldn't be too hard. I'm more concerned about the feasibility of keeping Scout App 2 up-to-date. If we have to do the compiling by hand and manually update the libraries, it's overhead that may cause the project issues in the future. I prefer more easily automated systems.

Grunt-Sass (Not yet)

This is my fallback if SassC doesn't work out. It would require several node-modules be loaded (Grunt, Grunt-Sass, Grunt-Contrib-Watch or some other grunt watch task). Which means we'd be reliant on multiple dependencies rather than a single one. This may be the best route though if we expand beyond Sass and also process HAML, Markdown, or CoffeeScript as well. But that's a bigger issue in general. However I don't think we should bother with LESS or Stylus though because personally I'd rather encourage those to die off so we can have the One-True-Sass!

Current Goals

Right now I'm just trying to reproduce the existing functionality from the Java/Air/Ruby version. Watch one folder, process and spit out stuff into one output folder. Come with Compass built in. At the moment I'm just trying to get a single project working. But eventually add in the ability to create multiple projects and store data locally. This will take a lot of work, but all seems very feasible.

Future ideas

After we can get a C based Sass implementation functioning we could look into also doing Ruby-Sass in Scout 2. NW.js can very easily test if Ruby is installed, and if so, unhide UI elements to offer that option. Don't know if we want to explore that path or not though as it seems all the focus is now being put on the significantly faster C version.

cdCorey commented 9 years ago

I tried switching from Scout to Coda's Sass plugin once -- having the Sass compilation built into my editor instead of requiring a separate program seemed like it would result in a more efficient workflow. Unfortunately, Coda's Sass plugin is based on the C port of Sass, not the official Ruby Sass, and as a result it crashed every time I tried to save a Sass file. That 98% compatibility number sounds good, but based on my experience, I'd say it means it's likely to be INcompatible with 2% of any given codebase. And if 2% of your code crashes the compiler, it's not exactly useful for the other 98%.

Just my two cents, but if this project goes down the route of SassC, at least for me it will be a complete non-starter.

TheJaredWilcurt commented 9 years ago

@cdCorey that 98.53% comes from LibSass's release page. And states (+1.47%) meaning they are working their way up to being perfectly in sync. I would wonder more if the implementation of SassC as a Coda plugin was what was crashing, rather than LibSass itself. Either way, you've made having a Ruby alternative a higher priority to me. But one thing at a time, right now I just want to get the thing to work.

TheJaredWilcurt commented 8 years ago

@zdennis @mejiaj

Update

So I finished my side project, UGUI, which is a framework for NW.js. I'm now focusing on the website for UGUI, tutorials for it, documentation, etc. However with the framework done, I've come back and revisited my first draft of Scout-App 2.0.

I've got a semi-functional version up and running. Right now all it does is accept an input and output folder and process the .sass and .scss files (skipping those that start with an underscore). It is currently accepting an output style (nested, compressed, ect.) however I don't believe that's actually working right yet.

Keep in mind the scope of Phase 1 is "Ugly but functional".

I'm thinking the tabs for each project can be stored as an internal object and then saved as a .json file that gets loaded when the app launches. May store all settings in there as well, or store them separately as UGUI has an easy to use save/load settings helper function. I'll either use the UGUI API for that or implement a custom solution borrowing heavily from it.

If you want to run it locally in it's current state you can follow the updated, easier, instructions in the README. I've updated the TO DO list on the README.

TLDR: Project has been updated. It's semi-functional. The instructions to run it locally have been simplified. There's a TODO list in the repo.

TheJaredWilcurt commented 8 years ago

Update. With the new issue of Windows machines being unable to install Scout 2012, I've been inspired to get back to work on Scout 2.0. Did some work on it last night.

I've created a chatroom for this, hop in and give input and help get version 2.0 off the ground.

JOIN THE CHAT! HELP MAKE SCOUT 2.0!

Gitter

TheJaredWilcurt commented 8 years ago

Update! Here are some screenshots. Not everything shown is functional yet.

scout-large scout-about scout-small

To play around with the current version:

  1. Install Node.js
  2. Download or Clone the repo:
  3. Run npm install
  4. Run npm start
mejiaj commented 8 years ago

@TheJaredWilcurt Daaamn, awesome work man! I checked out the previous prototype you posted but I was on windows.

TheJaredWilcurt commented 8 years ago

Added line-of-code error alerts. Still needs a lot of effort put into testing all the different alerts that can come up and how to handle them.

scout-error

Also need to add in successful Sass-to-CSS conversion alerts as well. All of these will go on their own Status page (accessible via the blue button). But that error screenshot is functional, all the unique data there is dynamic and fed in from Node-Sass.

Edit: The code preview idea came from this wireframe.

unspecified

TheJaredWilcurt commented 8 years ago

Since the new version of Scout-App uses Node-Sass instead of Ruby-Sass, we can no longer support Compass. Only the compass mixins. So we really shouldn't be using the Compass logo anymore.

With that said, we have Kim Sharpe (@kimmortal1) to thank for creating a new icon for Scout the Puppy!

Old Scout-App 0.7 logo, which is actually the Compass logo will be replaced with New Scout-App 2 logo

Scout the Puppy! His collar has the same hexagon used in the Node.js logo. I tried putting the "S" from the sass logo on it, to give it a "node/sass" feel, but it just looked bad. May revisit it in the future and change the collar to a scarf or something to have more room for extra details.

zdennis commented 8 years ago

The new icon looks great! Thanks @kimmortal1

TheJaredWilcurt commented 8 years ago

The app is finished and we got a new website:

Scout-App.io

So what now?

  1. Post Credits Spoilers
    • Who all should be added to the Scout-App v1 credits on the site.
    • @zdennis and @mejiaj Do you want to be credited differently on the site (other than username).
  2. Yall got issues
    • There are 173 Open issues for Scout-App, 99% of which are for 0.7.1 and before.
    • Since there has not been a release since 2012 of this version, I think it's safe to classify the classic version as deprecated and that there will be no more active development done on it by MHS or myself.
    • This means that these issues can be handled, linked to the new version, and closed. I'm happy to do this, but I will need to be added to the mhs/scout-app repo.
  3. To merge or not to merge.
    • My original intent was to fork Scout-App, and upon completion, merge it back in. Scout-App 2 shares no code in common with the original. It's a complete re-write.
    • Since the original is owned by MHS, they may not want their version replaced by the new one. Though I assumed they would be fine getting credit for the new version.
    • If we go this route I would definitely need to get access to the mhs/scout-app repo to make maintaining it easier/faster.
  4. Nothing ever ends
mejiaj commented 8 years ago

@TheJaredWilcurt Wow, I remember trying this when you first proposed the new version. Can't wait to check this out.

I've got no problems with the credit. Though, I'd like to help out more with the UI/Design, if possible.

TheJaredWilcurt commented 8 years ago

@mejiaj

Great, well the next big UX/UI thing we need help on is FTUX/Onboarding.

Whenever the app is in a state in which there are no projects (either you deleted all of them, or it is the first time opening the app) we load the First Time User Experience (FTUX) screen. Currently this screen looks like this in it's ideal state:

FTUX Good

But when Scout-App fails to find a projects folder on their machine, it looks like this:

FTUX Bad

This is a very confusing screen to see. The wording doesn't make sense and what actions you should take are unclear. I'm afraid people with only one project won't have a projects folder, and they will try to point to their project as the projects folder, and then import all their project subfolders as individual projects.

I'd like something where you are presented with a choice to do single project import, or multi-project import.

TheJaredWilcurt commented 8 years ago

@zdennis how do you want to proceed

Option 1: Merge

  1. APP - I create a pull request for mhs/master ... TheJaredWilcurt/Scout-App-2-Dev
    • This updates all of the mhs/scout-app repo to match my branch and pulls over all tags and releases bringing both repos up to parity.
  2. SITE - I create a pull request for mhs/gh-pages ... TheJaredWilcurt/gh-pages
    • This updates the website to be the same as what can be seen on Scout-App.io. Then I update the CNAME/DNS stuff to point to the correct URL, so that all of the links on the web pointing to mhs.github.io/scout-app will automatically take you to scout-app.io instead.
  3. MAINTENANCE - I'm added to the mhs/scout-app repo as a collaborator so I can push directly to the App and Site, and can clean up the issues on the repo.

Option 2: Split

  1. APP - I create a new GitHub organization and a repo in its name for the app and upload all the content from the current Scout-App-2-Dev branch to its master
    • This sets Scout-App 2 apart from Scout-App 2012, by no longer being a fork or carrying any of the commit history of the original or the making of v2.
  2. SITE - I create a new repo for the site on the new GitHub org based on the TheJaredWilcurt/gh-pages branch, then update CNAME/DNS info to point to the new URL.
  3. MAINTENANCE - This gives me access to an issues page for both the site and the app that I can control.
  4. OLD SITE - I submit a Pull Request against mhs/gh-pages to update the 2012 site to point to the re-release downloads of the 2012 app (that aren't broken, we get lots of issues about this still).
  5. OLD SITE - I submit a Pull Request against the mhs/gh-pages to mention and link to the 2016 version of Scout-App 2 on it's own separate site.
  6. MAINTENANCE - I update all issue template links to point to the new repo, and we close out any SA2 bugs from the mhs/scout-app/issues page.

Option 3: Both

  1. APP - I create a pull request for mhs/master ... TheJaredWilcurt/Scout-App-2-Dev
    • This updates all of the mhs/scout-app repo to match my branch and pulls over all tags and releases bringing both repos up to parity.
  2. APP - I create a new GitHub organization (scout, scout-app, and scoutapp are already taken, maybe scout_app or scout-the-puppy after the mascot). The mhs/scout-app repo is transferred to the new organization.
    • This will move all of the repo over, keeping its commit history, forks, and issues intact.
    • Myself and anyone from MHS will have access to this repo.
  3. SITE - The new site gets ported to a new repo in the organization named org-name.github.io. CNAME/DNS stuff gets updated so scout-app.io points to this new url. The old site remains accessible at org-name.github.io/scout-app.
  4. MAINTENANCE - All upkeep and issues are handled on the new organization with its transferred repos.

TLDR

  1. Option 1: My stuff gets merged into MHS repo, standard open source style, I get access to the MHS repo to handle issues and update the app/site.
  2. Option 2: I create a scout-app GitHub org and port my stuff over to it, losing the commit history in the process, but gaining control over an Scout-App 2-only issues board. Old site gets updated with a link to the new site and correct 2012 downloads.
  3. Option 3: My stuff gets merged into MHS repo, then the repo gets transferred to a new GitHub org retaining commit and issues history. Myself and anyone from MHS has access to this org for updates/issues. New site gets it's own repo, old site remains on the gh-pages branch.
zdennis commented 8 years ago

Thanks for all of your work and for laying the above out @TheJaredWilcurt ! Give me a few days to think on this. Will post back this week.

TheJaredWilcurt commented 8 years ago

Update: I was given access to the Scout-App organization by it's current owner who didn't seem to be using it. So that's pretty cool.

TheJaredWilcurt commented 8 years ago

Update 2: I've been given full ownership of the scout-app organization. I've invited @zdennis as a fellow owner of the org, and invited all other contributors as org members.

I've ported over the new website to the new org. These two URLs are now linked:

TheJaredWilcurt commented 8 years ago

Alright! New plan! Now that we have a sweet Org name and I've ported the new site over to it, things have changed a little. So here's my new plan, lemme know what you think:

  1. We transfer the github.com/mhs/scout-app repo over to github.com/scout-app/scout-app. This pulls all the issues along with it and updates all previous forks and references to point to the new location.
  2. The gh-pages branch that hosts the 2012 site (mhs.github.io/scout-app) will will be moved as part of the above transfer and reside in the new organization accessible via a new url (scout-app.github.io/scout-app). So it will still be around, and not overwritten by the new site. However, links to the old URL will not auto-forward.
  3. So at this point the App repo has been transferred and the 2012 site now resides at a new URL and the old URL no longer exists. Because a lot of sites out there still point to the old URL, a new github.com/mhs/scout-app repo should be made with a gh-pages branch with a page stating "Site has moved", with links to the 2012 and 2016 versions of the site (probably with logos or screenshots).
  4. The newly located 2012 site should be updated to have correct downloads from the 0.7.1 re-release (to stop the endless issues being made about the downloads not installing right).
  5. The 2016 site should link back to the 2012 site for "Scout-App Classic", since the 2016 version does not use Ruby Sass or have full support for Compass.
  6. Merge the TheJaredWilcurt\scout-app:Scout-App-2-Dev branch into the transferred scout-app\scout-app:master branch.
  7. Update the README's and Site links to point to all the new locations.
  8. Clean up the issues board, out of the 176, it's probably safe to assume that at least 150 are no longer relevant.

So there's my new plan. Let me know if I missed anything or if you want to do things differently.

Who does what:

zdennis commented 8 years ago

@TheJaredWilcurt wrote:

I was given access to the Scout-App organization by it's current owner who didn't seem to be using it. So that's pretty cool.

That's great!

I've ported over the new website to the new org. These two URLs are now linked:

https://scout-app.github.io http://Scout-App.io

w00t!

ZD: Transfer the github.com/mhs/scout-app repo over to github.com/scout-app/scout-app. ZD: After the transfer is complete, create a new github.com/mhs/scout-app repo with a gh-pages branch.

Working on this part now.

zdennis commented 8 years ago

Okay, transfer is in progress. I will circle back and create the scout-app repos and gh-pages once it's done.

zdennis commented 8 years ago

Bare mhs/scout-app repository is up https://github.com/mhs/scout-app with gh-pages branch.

TheJaredWilcurt commented 8 years ago

To do list:

TheJaredWilcurt commented 8 years ago

Transparency: I'm sending the following to GitHub Support.

I'm in the process of porting over several months of work from a forked repo back into the original that was just transferred to a new organization and can't get my releases to transfer over.

The process we have gone through can be a little confusing, so let me sum up the history of the project:

  1. MHS created the scout-app repo with a master branch at github.com/mhs/scout-app:master
  2. TheJaredWilcurt forked the master branch to github.com/TheJaredWilcurt/scout-app:Scout-App-2-Dev
  3. TheJaredWilcurt did several releases on his fork.
  4. TheJaredWilcurt became the owner of github.com/scout-app
  5. MHS transferred github.com/mhs/scout-app to github.com/scout-app/scout-app
  6. TheJaredWilcurt did a Pull Request to merge TheJaredWilcurt/scout-app:Scout-App-2-Dev into scout-app/scout-app:master
  7. This pull request was accepted and the scout-app/scout-app repo was updated. However the releases that were created on TheJaredWilcurt/scout-app did not carry over.

I would like for those releases to be moved to the new org/repo (I'm the owner of both) so that the download statistics and publish dates for them stay intact since we are using the GitHub API on our website for the project. Re-doing these releases on the new org/repo would require pulling from two different routes, parsing the releases from each, matching them and then manually combining them to get accurate statistics and release dates.

It would be far more convenient to just have the releases transferred to the new org/repo, and it would also be historically accurate with the date of publishing.

I don't care if links to the old releases forward to the new ones, that doesn't affect us.

TLDR: I'm the owner of github.com/TheJaredWilcurt/scout-app and github.com/scout-app/scout-app. I want to move the releases from the first over to the second.

TheJaredWilcurt commented 8 years ago

GitHub support replied and is of no help:

Hi there, I'm afraid it isn't possible to transfer releases between forks I'm afraid. These would need to be created manually on the scout-app/scout-app repository. Pull Requests only contain commits and not tags. For a more automated solution, perhaps our releases API can be of some help: https://developer.github.com/v3/repos/releases/ Sorry we couldn't be of more assistance. Please let me know if you need anything else.

So I move on, and I check off things on my list. Manually recreated the last two major releases. Updated the Classic site to be a little more optimized and point to the new links.

To do list:

TheJaredWilcurt commented 8 years ago

Updates

All that is left is to clean up the issues board, and finish editing the Getting started video and this whole process will be complete.

TheJaredWilcurt commented 8 years ago

Video uploaded and added to the site. Started in on the 176 issues. 99 left...

TheJaredWilcurt commented 8 years ago

50 left...

TheJaredWilcurt commented 8 years ago

And then there were 15 issues left of the original 176.

161 closed.

With all of the to-do's marked off the list, a functional new version of Scout-App released, a new website, and new GitHub organization, I feel safe saying that Scout-App 2 is complete and is a success. I think it's safe to close this issue now.

Thank you to @zdennis for all the help, and to @mejiaj for the great design ideas.

I've updated the Project Road Map to link to all the requested features already on the GitHub issues page.

I will be creating new META issues, like this one, to plan and design around ideas for how to implement new features in the most simple and intuitive way.

And to @kavillock and @cdCorey be sure to try out Scout-App 2.