Skip to content

Site Structure #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ForbesLindesay opened this issue Dec 24, 2012 · 11 comments
Closed

Site Structure #1

ForbesLindesay opened this issue Dec 24, 2012 · 11 comments

Comments

@ForbesLindesay
Copy link
Contributor

I propose the following site structure:

/ => The site's home page should contain a listing of all available components (paged if need be) with a search box and links to a few other key parts of the site. The components in this listing should display their license and number of stars on GitHub. They should be grouped by category based on the wiki, and sorted by number of stars in GitHub, then alphabetically within that.

/about => this userID is not available in GitHub, I think it should contain an introduction to Components + a Getting Started guide with accompanying video and a few sample projects in GitHub.

/:user => should show a listing of all the components a given user has produced, it should look very much like the one displayed on the home screen.

/:user/:repo => The primary listing page for each component. It needs to display some key info about the repo: browser compatibility based on automated tests, License, number of stars, dependencies, dependants, installation instructions/links to different pre-made builds. I would like to also display the readme with an automated table of contents so that this can be used as the home page for most components.

/:user/:repo/download => Listing for downloads of the component. This should include minified and unminified. standalone builds of each version of the library, it should also include a build of the library that doesn't include any dependencies or the require script so that you could have:

<script src="https://component.io/require.js"></script>
<script src="https://component.io/foo/bar/download.js"></script>
<script src="https://component.io/foo/baz/download.js"></script>
<script>
  var bar = require('bar');
  var baz = require('baz');
</script>

We need to decide exactly how we structure the URLs for download links. We need to have at least one link to the latest standalone unminified build as that will allow us to get most of the components submitted to microjs.com (see microjs/microjs.com#344)

/component-badge.svg => should serve the SVG for the component badge:

badge

Anyone got any to add/not like any of these?

@ForbesLindesay
Copy link
Contributor Author

How do you want these separated into express apps @visionmedia ?

We could do one for home, one for each of those url schemes?

@tj
Copy link
Member

tj commented Dec 24, 2012

I have some graphs I'd like on the homepage too, still tweaking the design but I'll try to get that done soon. The urls look good but I wouldn't go too nuts with the standalone downloads thing, non-minified is enough IMO, pre-minified doesn't make any sense these days everyone has a production build step which does this anyway, and I dont want to people to get confused thinking standalone versions are a good thing, they're still a "bad" way to develop apps but available if necessary. I like the badge but it's easily 2x too big IMO

@buschtoens
Copy link
Contributor

I propose the following changes:

/ => should be a real homepage, with @visionmedia's graph of components count, some short description and installation/usage notes. /about then contains more information.

/about/statistics => would also be interesting. Graphs and stuff. What do we have? Count of components, devs, keywords, stars. Sadly we can't track the downloads.

/index/:keyword?.:format? => is the list of all components, optonally filtered by a certain keyword. With search box, etc. We certainly need pagination, or would you prefer infinite scrolling? An json/xml representation of the list would be useful as well.

@buschtoens
Copy link
Contributor

@visionmedia The badge can be easily scaled down. :) We could even allow the devs to entirely customize their badge. silvinci/component-badge
Shall I add the option to place the number of components on the right of the logo?

@tj
Copy link
Member

tj commented Dec 24, 2012

we could track downloads if we wanted to, we can just fire off tiny requests to component.io on install.

noooo customize badge hahaha unified is good :D but cool I didn't see that.

I have mixed feeling about search on the homepage, on one hand it's insta-available which is nice but it would be at least one viewport-length down the design anyway so yeah maybe a separate page is best

@ForbesLindesay
Copy link
Contributor Author

I agree that standalone is bad in the long term, but it's necessary to encourage adoption and break the chicken/egg cycle. The non-standalone builds are also really important.

I'm fine with the badge being smaller.

I think perhaps we should go for a super minimal home page with a really brief description of component followed by links to more info, graphs and the listing pages.

@tj
Copy link
Member

tj commented Dec 24, 2012

I'm not too too concerned about that, it would be nicer to get people using the tool(s) the correct way and getting the full benefits and having a better feeling about it in general, rather than just the same old crappy script tag method we've all been dealing with for ages

@buschtoens
Copy link
Contributor

The search box on the homepage could issue a real POST request to /index, providing an insta-available, but seperated search. On the /index the search box would send an AJAX POST request on /index.json, and then auto update the page.

I'm on TJ's side on this. A simple download should satisfy those, who don't want or can't yet switch to the new build.js.

@tj
Copy link
Member

tj commented Dec 24, 2012

@silvinci yeah totally, or the search results could "replace" the index page content so it's not in the way, we'll see

@ianstormtaylor
Copy link
Contributor

couple ideas for search:

i think it would be nice to auto-focus the search on keydown (and add the key that was pressed) so i can just load the website and start typing to search.

also for the page height away problem, focusing the search could scroll you down if you're too high up to see the results

@jonathanong
Copy link
Contributor

site is static now, so we need #73 for users/repos, etc.

still want #67 and #75 tho

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants