search

tighten / onramp

Easing the onramp for new or non-PHP developers to become Laravel devs.
https://onramp.dev/
MIT License
159 stars 56 forks source link

Decision: Should resources attach to skills? #121

Closed mattstauffer closed 2 years ago

mattstauffer commented 5 years ago

Right now skills are attached to modules and resources are attached to modules. I think there are a lot of reasons to attach resources to skills. But are there any circumstances in which this would be a problem? E.g. a resource covers many skills? Is there a clear way to handle that?

See #25 for a bit of discussion in the comments.

rockymontana commented 5 years ago

By making the skills a first class citizen it could have its own index/show pages. Then it wouldn't matter if one resource BelongsTo or BelongsToMany as they would be shown the same way it would in a module.

I will think about other potential pitfalls and see if there's anything that comes to mind.

I'll do this one if we decide that we are going forward with it.

mattstauffer commented 5 years ago

šŸ‘šŸ» I could definitely imagine this being a valuable decision.

Also.. one idea.. even if a resource DOES apply to multiple skills... we can handle that logic on the module page, so if a resource might show up three times (because it addresses three skills) we can just group it and show it once on that page.

rontu85 commented 5 years ago

But do you really get a skill three times? I mean, if you fetch a module and its related resources and skills you will get everything only once. Even if you have a relation between skill and resource. Or would you load all resources of a module and then the related skills of these resources?

rockymontana commented 5 years ago

Yeah you would since you retrieve them from the respective relation (skill, modue, what-not). I don't think it's worth fetching the skill resources from the modules however, but seperate that completely and make the skill itself clickable from the modules view and then list the skill-based resources from its own view.

mattstauffer commented 5 years ago

I'll have to think about it but right now I'd rather keep the resources on the module page.

Imagine there's an "introduction to making web sites" course that's fantastic and it covers HTML, CSS, and basic JavaScript.

That resource would be attached to those three skills, and I would want those skills and that resource to all show on the module page.

@rontu85 Yah, I mean less the practical details of loading it, and more ideologically, is it OK to have a single resource that, instead of being attached to a single skill, is attached to multiple skills? I think the answer is yes, but just had to come to it.

jonsugar commented 5 years ago

I read #25 for context as I didn't understand why the question was being asked. To make a TL;DR is the question "Should we make Skills a (or the) top level element".

My thinking is no, the current model is correct. I think we should be outcome focused not skill focused.

Now starts my long explanation of why. Note: this is all just my perspective and how I view things.

Using the simplest use case firstā€“brand new developerā€“I imagine a structure like this. Note order is important, the top level elements are outcomes and the second level items are the skills that the person learns. Each top level item builds upon the previous one because the user changes the code they produced in the previous module using the skills they learn in the current one. From module 3 onwards they will have a series of commits in git. They will literally see their learning progress in code.

Full course (new) developer

  1. Set-up your development Environment
    • Learn Terminal.
    • IDE/Text Editor.
  2. Build a basic web site
    • Learn HTML
    • Learn CSS.
  3. Manage your code using Git
  4. Build a dynamic website with PHP
    • Set-up PHP
    • Learn basic PHP
    • Learn Object-Oriented Programming in PHP
  5. Build a dynamic website with Laravel
    • Set-up basic Laravel tooling (composer, valet, laravel Installer etc)
    • Learn basic Laravel (routing, blade)
    • Learn intermediate Laravel (Database, Restful Controllers and Eloquent)
  6. Enhance a website using JavaScript
    • Learn Basic javascript
    • Learn Vue or Learn React (would introduce Laravel Mix)

Starting with "Build a basic website" the user will go through the learning resources and complete a test at the end. The test being build some static HTML styled with CSS based on the Private Instagram specification.

Next, the user learns about Git and why it's used. The end of module test may be to add or change some of the code and commit it. Again, the changes will be based on the Private Instagram specification.

The next module introduces PHP. After completing the learning resources and the test the user will have several iterations of their code in git. The current iteration of their code will be served by the built in PHP server and have simple dynamic features implemented using plain old php.

In the Laravel specific module the tests would have the user install the core laravel development tool chain. Next they would take the plain old php code and move it into simple routes and views. Finally, the dynamic aspects of the site are migrated from plain old php into database migrations, eloquent and restful controllers.

The final main module would be Javascript related. The user gains an understanding of how javascript can enhance the user experience. They learn basic javascript followed by Vue or React. The test would have them implement some enhancements to their code using Vue.

Partial Course (Wordpress or front-end) developers

For users who already have some of the required skills, modules should be skippable or tailored via an upfront wizard.

Wordpress Theme Developer

Modules 1 and 2 above may be of no interest to Wordpress theme developers, Github might be (assuming not in this example).

In this scenario some pre-made code would be provided that approximates what the user would produce if completing modules 1-3. The user starts from the module "Build a dynamic website with PHP".

  1. Build a dynamic website with PHP
    • Set-up PHP
    • Learn basic PHP
    • Learn Object-Oriented Programming in PHP
  2. Build a dynamic website with Laravel
    • Set-up basic Laravel tooling (composer, valet, laravel Installer etc)
    • Learn basic laravel (routing, blade)
    • Learn intermediate Laravel (Database, Restful Controllers and Eloquent)
  3. Enhance a website using JavaScript
    • Learn Basic javascript
    • Learn Vue or Learn React (would introduce Laravel Mix)

Front-end Developer

Modules 1-3 above may be of no interest to front-end developers. Depending on their prior experience either Vue or React may be of interest. In this example I will assume prior experience with React.

The user starts from the module "Build a dynamic website with PHP". In this scenario the javascript module no longer displays basic Javascript as a resource. The resource for learning Vue is specifically tuned for React developers.

  1. Build a dynamic website with PHP
    • Set-up PHP
    • Learn basic PHP
    • Learn Object-Oriented Programming in PHP
  2. Build a dynamic website with Laravel
    • Set-up basic Laravel tooling (composer, valet, Laravel Installer etc)
    • Learn basic laravel (routing, blade)
    • Learn intermediate Laravel (Database, Restful Controllers and Eloquent)
  3. Enhance a website using Vue
    • Vue for React developers (would introduce Laravel Mix)

By making the skills a first class citizen it could have its own index/show pages. Then it wouldn't matter if one resource BelongsTo or BelongsToMany as they would be shown the same way it would in a module.

I will think about other potential pitfalls and see if there's anything that comes to mind.

I'll do this one if we decide that we are going forward with it.

The glossary can have a filter for "show only skills" Using the already implemented deep linking will provide them access to the appropriate resource(s).

rockymontana commented 5 years ago

@jonsugar I really don't see how skill based resources targeting broader concepts contradicts anything you say here to be honest. I rather see it as something that helps you get a birds eye view of things.

Think of it the same way we're using the glossary. I bet that some (if not even many) users will go through the glossary and read about the terminology all in one go, even though they're not reaching it from the modules. The same way I think people would be interested in reading things like PHP Panda in one go to get familiar with things like syntax or format or whatever and then go through the modules.

You are saying that we should be more outcome focused than skill focused, but that's not at all what's being discussed (at least not from my part). I agree that it should be outcome focused. I just don't agree that there's only one way of doing it because it really depends on who you are.

jonsugar commented 5 years ago

You are saying that we should be more outcome focused than skill focused, but that's not at all what's being discussed (at least not from my part). I agree that it should be outcome focused. I just don't agree that there's only one way of doing it because it really depends on who you are.

Thanks @rockymontana for your reply, it forced me to think about what I was trying to say and give it some context which I did poorly in my previous reply.

At the moment we have yet to define:

  1. The overall UX and UI for onramp.
  2. How the Upfront Wizard will affect the user journey.
  3. How we will plug the concept of the private Instagram project into the Onramp user journey.

Within the context of the points above, I was trying to illustrate how I see modules, skills and resources relating to each other which is what this issue is about. I know I'm broadening the scope of the discussion but I don't think you can answer this issue properly with out first resolving those points.

One of the things that stuck in my head was a comment by Zuzana when she said "she wants to understand the bigger picture when it comes to building full stack apps". In my reply I was trying to think about that.

I see Onramp as leading the user through their learning and providing them the opportunity to produce real code through tests. In explaining that i'm saying there is no need to relate skills to anything beyond explaining what the user learns in each module.

I hope this all makes sense and sorry for derailment.

rontu85 commented 5 years ago

I just stumbled across a potential edge case. Letā€˜s assume we have a skill called SQL and two related resources. One is Basic SQL and the other one Advanced SQL. Should both be part of a module which has SQL as a related skill? Or do we want to exclude the Advanced SQL resource because the module is more about basic stuff? Or is this no problem?

mattstauffer commented 5 years ago

I think that @jonsugar's comments here about being outcome-focused are good. I think @rockymontana is right that we can answer this architecture question without it defining our UI. And @rontu85 I think that if we have the idea of an advanced SQL course, if we want it in a separate module then it'll be a separate skill (write basic SQL vs write advanced SQL) so that's handled.