Hi Greg,

OK, I'll take stab at this. I'm sure others can weigh-in with more/better insight... And we all understand "how hard would it be to" is all relative to a developer's experience, right?

Sounds to me like you're talking about building an articleLevelProgress extension. If you haven't yet jumped into plug-in development, I think this is the perfect scenario. You know quite clearly what you want to achieve AND you have a well-functioning model plug-in, pageLevelProgress. Similar to what has been suggested for modifying the Vanilla theme, make a copy and start playing with the code. Personally, I would recommend that you develop plug-ins using the framework. I'd hold off on bringing the authoring tool into play until you're reworking properties.schema (and in this particular case, that file might not even need any reworking).

Below is my take on what pageLevelProgress does and what I imagine you want articleLevelProgress to do.

pageLevelProgress:
- displays overall progress (components collection) in the navbar
- displays individual component titles and progress in the drawer
- provides navigation by jumping from component title listed in the drawer to its location on the page

articleLevelProgress
- displays overall progress (components collection) in the navbar
- displays individual article titles and aggregated progress of an article's components in the drawer
- provide navigation by jumping from article title listed in the drawer to its beginning on the page

Based on this understanding, here's what I see (BTW The object names can get confusing; I've tried hard to be precise.):

adapt-contrib-pageLevelProgress.js defines two objects/classes:
PageLevelProgressNavigationView
PageLevelProgressView
As Backbone views, both have their associated Handlebars template in the templates folder.

Since the progress is ultimately based on the learner working through the components, the progress bar that is displayed in the top nav bar doesn't have to change. That means:
- PageLevelProgressNavigationView could stay the same (well, maybe except for onProgressClicked().
- pageLevelProgressNavigation.hbs could stay the same.

PageLevelProgressView is where I think most of the changes would be introduced. There's a few areas I would focus in on.
- The "router:page" event is assembling the components and passing them to setupPageLevelProgress() so they can be made into a collection. That collection is in turn used to create a new PageLevelProgressNavigationView. The PageLevelProgressNavigationView uses this collection within updateProgressBar() to calculate how wide the indicator should be. So this calculation is made using components; no problem here. However, when the progress bar is clicked, onProgressClicked() is called and this same collection (of components) is used to create the PageLevelProgressView. PageLevelProgressView is what is used to build drawer's custom view. This is where you need to alter the code to ensure that it uses a collection of articles rather than a collection of components. Render() is passing component data to pageLevelProgress.hbs. You need to ensure article data is accessible there, too, so you can display the title.
- pageLevelProgress.hbs uses the component's _isComplete attribute to set the progress bars that are displayed in the drawer. You'll need to figure out what to use instead to determine if an article is complete. I haven't checked to see if there is a comparable article attribute. (I suspect not.) You may need to loop through each article's components to see if all are complete. Heads up: the components' progress bars in the drawer are "boolean" in that they are either complete or they're not. There's no range indicated. You'll have to decide if that's adequate for articles. If you need to display a percentage of components completed, you've reached a new level of complexity. BUT you have updateProgressBar() as a model. Perhaps you can introduce something similar to PageLevelProgressView.
- scrollToPageElement() needs to be reviewed to ensure that it continues to work with articles.

This is just a quick perusal of the code to help you with your own analysis. Any strong statement above should be read with a "probably" or a "might" inserted in it somewhere :-)

Greg, hope this helps in some way.