search

OpenUserJS / OpenUserJS.org

The home of FOSS user scripts.
https://openuserjs.org/
GNU General Public License v3.0
857 stars 303 forks source link

UI: Vocab & Bootstrap? #103

Closed Zren closed 10 years ago

Zren commented 10 years ago

Edit:

Currently redoing the UI with Bootstrap & FontAwesome & whatever is needed.

Demo: http://nameless-hollows-5487.herokuapp.com

Progress

Discussion Category

Original Post:

Seeing as most users are probably coming from Userscript.org, I'm wondering why you changed some of the vocabulary.

Looking at the UI made me want to redo the entire thing. When checking out the tracker I also saw #77, and thought if you're going to implement it for a 3rd parties, you might as well use it for the site as well. This made me think of http://datatables.net/. I noticed that NodeJS + Mongoose has a package for it on the server side https://www.npmjs.org/package/mongoose-datatable. Now I haven't checked into SEO with DataTables, so I'll have to look further into it. Anyways, I made a quick demo with it and Bootstrap 3.

http://codepen.io/Shadeness/pen/zBomq

I also tried cloning Userscript.orgs frontpage (without DataTables this time).

http://codepen.io/Shadeness/pen/LmyFB

Essentially, I wanted to point out that Bootstrap + FontAwesome would help make the site look less like it came from the 90s and more like it's a copy-paste site from the 2010.

Zren commented 10 years ago

Uhg. Need sleep.

Left:

Does /graveyard and /flagged work?

jerone commented 10 years ago

Great work, have been following your progress behind the scenes!

Uhg. Need sleep.

http://nameless-hollows-5487.herokuapp.com/?library=true

The install button on a library page isn't necessary.

sizzlemctwizzle commented 10 years ago

Does /graveyard and /flagged work?

Yes, but they don't have support for comments yet and the graveyard isn't finished (it should let moderators undo removal).

Martii commented 10 years ago

Is flagged where the threshold is reached and then it becomes flagged? ... because I don't really see any other option to "flag" something.

sizzlemctwizzle commented 10 years ago

Is flagged where the threshold is reached and then it becomes flagged?

Yes and then it can be removed by moderators.

because I don't really see any other option to "flag" something.

You're an admin. You can't flag. You just remove.

@Martii I'm just going to remove this script and user. I've read enough of the obfuscated code to know that it tries to send a report user request on FB. This is not what it says that code does in the comments so it goes against the "doesn't do what is advertised" rule. It is intentionally misleading.

This user is clearly a scammer. Their scripts send requests to "like" several predefined profiles (or in some cases submit a friend request), and promise the user that they will receive likes on their profile if they install the script. This is totally misleading and a scam. I'm going to remove this user as well. I just don't have patience for stuff like this.

Martii commented 10 years ago

remove

I kind of figured that but didn't want to overstep until the TOS is established some more in #116

You can't flag.

Interesting... there may come a point when this is needed due to time constraints or general "not sure"... but if it's based off of the rating exclusively I suppose that could work... the "undo" option might be a good thing too instead. Thanks.

sizzlemctwizzle commented 10 years ago

there may come a point when this is needed due to time constraints or general "not sure"...

I think maybe someday we'll add the ability to have a moderator discussion on a script for those tricky cases (which would be visible to all moderators and admins on some sort of dashboard thing).

but if it's based off of the rating exclusively I suppose that could work...

No, there is real flagging for non-admins (however an upvote does count against a flag). But since admins are basically not a part of that user moderation system (users flagging and moderators removing once the threshold has been met), I don't think they have a right to flag something. Plus there's the potential that admins could be targeted which is why they can't be flagged (moderators just have a higher threshold). Admins can see the number of flags on something (non-admins can't so we don't cultivate a hivemind) to help identify something that might need reviewing. I imagine the site one day having a ton of moderators (since we don't have to put to much trust in them) and a few admins.

the "undo" option might be a good thing too instead.

Yeah that's a big deal in making the system work. If someone screws up, we can always fix it (right now it's completely manual).

Zren commented 10 years ago

"Load Scripts" is a VERY unoptimized route. It basically hits every folder of every single repo you own (that's not a fork). Not supporting importing from forks is silly as well. Anyways, that's a sure fire way to eat up our Rate Limit allotment (5000 / hr for each of GitHub's api categories). Since I've no idea what the output of that is (as it takes forever and breaks when it does output), I'm not quite sure what it looked like.

It looks like that route was mostly useless anyways, as it has nothing to do with syncing. Syncing hadn't been working for me as I just wasn't uploading the script first.

NewScriptPage

Note: Import (URL) doesn't work.

GithubRepoPage

Import script from Github Repo & List instructions for synchronizing.

Now with checking blob.size!

To complete this page I'm thinking of adding an optional /.../upload?url= route for the "Import" buttons. That'll take a bit of work. I'm going to leave out the GitHub specific pages for the ui PR so I can mess around with them more.

Martii commented 10 years ago

Firstly, the script must already be uploaded to the site.

This isn't currently true... the import process automatically posts to the site... is this behavior changing?

Zren commented 10 years ago

This isn't currently true... the import process automatically posts to the site... is this behavior changing?

Import = ?

Pushing to a repo with a webhook set? This currently does not add new scripts (found through testing on oujs.org). It will update existing scripts however.

Or is that the List Scripts buttons that does hundreds of requests and takes a minute and doesn't work?

Edit:

Should note that I did these tests on https://openuserjs.org/

http://i.imgur.com/1BPBVX3.png

https://github.com/ZrenTest/TestUserScript/blob/master/TestUserJS.user.js

https://openuserjs.org/users/zrentest

Edit:

So it does work, on ZrenTest at least. Zren probably has way too many directories in all my repos and times out on the request maybe. The github api actually paginates the request for all my repos (which I don't think we handle?). I also discovered https://github.com/mikedeboer/node-github which might help.

When fetching a repo tree, you can optionally set the request to be recursive: https://developer.github.com/v3/git/trees/#get-a-tree-recursively

It works on ZrenTest though. http://i.imgur.com/t4IbEMy.png and now that I've seen the form, I should be able to implement importing.

sizzlemctwizzle commented 10 years ago

@Zren Imo the best way to improve the import feature is to just automatically list their GitHub repos (this is a single GH api call, or a few in the rare case of pagination) and let users choose which ones we should scan for scripts. This should probably be done via some client-side JavaScript (interfacing with our server via JSON api), or initiated by the click of a button, so they don't have to wait for this to load to use the other methods to add scripts.

Not supporting importing from forks is silly as well.

I did it partly to lower the number of requests, and also because I want people using the site to fork. I don't know, maybe we should provide a link on imported scripts back to GitHub.

It looks like that route was mostly useless anyways, as it has nothing to do with syncing. Syncing hadn't been working for me as I just wasn't uploading the script first.

Just because it doesn't work for you doesn't mean it hasn't worked for others (including myself). I didn't test it on an account that had a ton of repos. I see you got it working on a test account.

This currently does not add new scripts

Intended behavior. You need to explicitly tell us what scripts you want us to publish via importing first.

I also discovered https://github.com/mikedeboer/node-github which might help.

This provides a ridiculous number of features that we don't need (or will probably ever need). Dealing with the GH api is pretty simple and this would be overkill for what we're doing (we already have plenty of dependencies already). Edit: Meh go ahead and use it if it really makes things easier.

The github api actually paginates the request for all my repos (which I don't think we handle?)

Not yet but this could be better fixed by using a JSONP library.

When fetching a repo tree, you can optionally set the request to be recursive:

That might kill us memory-wise. I think it's better to load many small JSON parsed objects into memory asynchronously than a few huge ones. It's the reason I import the script data by using the raw link instead of using the JSON api (it can be massive when loaded into memory).

To complete this page I'm thinking of adding an optional /.../upload?url= route for the "Import" buttons.

I'm not crazy about this. Basically it makes it super simple for users to add a script that isn't theirs. I really don't see a good reason to add this feature. If we do, we must link back to where the script was imported from.

Zren commented 10 years ago

client-side JavaScript

Would have to have a seperate github oauth id/key for that.

Edit: Meh go ahead and use it if it really makes things easier.

yay.

/.../upload?url= ... I'm not crazy about this.

Not going to do it then as I'm not sure how to apply limits while uploading anyways. Least we can check the github blob size before hand.

POST http://nameless-hollows-5487.herokuapp.com/users/Zren/github/import
Form Data:
    user: Zren
    repo: OpenUserJS.org
    path: libs/markdown.js

Noticed that GitHub import didn't support importing JS libraries.

Initial code for the redone githubImport.

sizzlemctwizzle commented 10 years ago

Would have to have a seperate github oauth id/key for that.

I meant the client-side JavaScript would interact with the server-side via a JSON api.

We could also make the import button submit an ajax request

This is probably the best option, but POST works for now (could you use target="_blank" or the equivalent for forms? Is there one?).

Add ability to import javascript libaries.

So you're solution for the no name problem is to just use the file name minus the ".js"? I guess that works since I can use spaces in filenames on GitHub.

Repo page does filter out files that are not JS.

Meh, not important imo. They are supposed to know which repos they want to import scripts from.

One more thing: I don't see the "Edit Meta" link on my scripts anymore. Did you move this somewhere? Also on the 404: it's "you're" not "your". Oh, and the "Add Webhook" link here is broken.

Anyway, very nice work. Much more usable than what we had. It loads noticeably faster and is simple to use.

Zren commented 10 years ago

The install button on a library page isn't necessary.

Is now labeled as Raw Source.

I don't see the "Edit Meta" link on my scripts anymore.

Oops. Typo'd when changing a check for options.isYou to options.authorTools, in case we change the controllers to allow moderators to view those links in the future.

Edit:

Martii commented 10 years ago

The install button on a library page isn't necessary.

Is now labeled as Raw Source.

Raw Source implies zero formatting including any configured headers... are you sure this is what the labeling should be? It was quite confusing when I visited briefly one of the other sites and definitely not as intuitive as a plain old "Install" (the libraries, as pointed out earlier, are a special case for not directly installing usually). As I've been with GH since the early days I personally am quite familiar with this nomenclature however not everyone is especially if they aren't an author. Usually shorter strings are easier to manage too along with potential "word play". (think installWith) More things to think about. :)

and if so, open in a new tab.

Do 100% of all browsers now have tabs 100% of the time?

The user could middle click the import button to remain on the import page.

How does one "middle click" on a cell phone?

Zren commented 10 years ago

I was following what the upstream branch was calling it that button.

  1. Remove "Install" button on libraryPage.
  2. Move "Raw Source" button on libraryPage to libraryViewSourcePage.
  3. Leave as it origionally was labeled as "Install" even on libraryPage.
  4. Rename it to "Raw Source" only on libraryPage.
  5. ?
Martii commented 10 years ago

The site revamps you are doing look great... I'm just trying to leverage some of the learning curve for others. We all have our skill sets but sometimes changes are needed for compromise so we don't leave the inexperienced in the dust. :) (btw more questions that should be asked above)

On listings of multiple scripts where there is a version, add a "v" in front of it, like so:

This could be a nightmare with translators and takes up screen real estate... best to just leave the versioning as is. I grew up with v1.0.0 but soon realized that it wasn't as good of an idea as I was led to believe. A user.js would be more of a suitable place for this for those who want it.

but POST works for now

Yah I'm getting both anxious and excited for the remodel of the UI to be nearing live... both the original and Zrens are nice but we don't need a complete remodel of every plumbing aspect right off the bat... "open open open open" :) ;)

Zren commented 10 years ago

Do 100% of all browsers now have tabs 100% of the time? / Phones

I changed it from a POST request (form data send in the body of the request) to a GET request (query string parameters in the url). I'm using <a target="_blank"> (now) which works is IE6 (creates a new window). It works on my Nexus7 (chrome) as well. If it doesn't support tabs, it'll just open like a regular link.

On listings of multiple scripts where there is a version, add a "v" in front of it, like so:

I'm opting not to do this as some scripts have v1.2.3 as their version, and vv1.2.3 looks weird.

Zren commented 10 years ago

@sizzlemctwizzle

That might kill us memory-wise. I think it's better to load many small JSON parsed objects into memory asynchronously than a few huge ones. It's the reason I import the script data by using the raw link instead of using the JSON api (it can be massive when loaded into memory).

Does nodejitsu have a low mem req?

Zren commented 10 years ago

I think I'll keep the old checkbox UI under github/ and link to github/repos from it, but only list at most the 10 5 3 most recently updated repos. That should keep if from taking too long and tearing up our rate limit with tree requests.

Edit:

Done: http://nameless-hollows-5487.herokuapp.com/users/Zren/github

ToDo:

Other than that, I'm going to freeze this for a PR.

sizzlemctwizzle commented 10 years ago

We have 2 drones (seperate instances of our app) that have 256MB of RAM each. On Jun 9, 2014 4:21 AM, "Chris Holland" notifications@github.com wrote:

@sizzlemctwizzle https://github.com/sizzlemctwizzle

That might kill us memory-wise. I think it's better to load many small JSON parsed objects into memory asynchronously than a few huge ones. It's the reason I import the script data by using the raw link instead of using the JSON api (it can be massive when loaded into memory).

Does nodejitsu have a low mem req?

— Reply to this email directly or view it on GitHub https://github.com/OpenUserJs/OpenUserJS.org/issues/103#issuecomment-45473939 .

sizzlemctwizzle commented 10 years ago

Closing this because of the merging of #129. If there's anything left, create new issues.