View Outlooks 1

[chrisdmacrae]

I'll start leaving observations for what views are needed as Issues. I'll sort these by blocks on site, i.e.: home, navigation, printable view, etc. There may be overlap and/or already existing features in these observations. If you have any questions fire me an email at personal@christophermac.me as I'll get back faster than via github.

// // Homepage

• Needs to generate a list of the most popular printables of the day and/or week and/or month. The overhead of this is beyond me, but I imagine some sort of algorithm to factor in upvotes/downloads/comments and staff interest is needed to decide what is "popular".

// // Header/Navigation

• Currently housed in a template with if/and statements. If this is the desired implementation, I will use this to import both the mobile navigation and desktop navigation.
• Search box needs to submit to the /printables/ directory. Implementation is down under "Search/Tagging"

// // Search/Tagging

• Search needs to be implemented by combining tags that are separated by commas and appending them to the printables sub-path (this is by far the best implementation of search from a UX standpoint) eg. /printables/mathematiclal+household. This in turn needs to then check if tags are in use, and create an array out of them that can be printed to the screen in the tag bar to be added/removed as the user desires via it's own template.

// // Printable Sub Path

• NOTE: a discussion needs to be had about how to display categories to the users. Right now the implementation to display sorting doesn't support a straight-foward way to break-down into category.
• Printable sub-path needs to output a paginated view of models sorted by popularity by default.
• The ability to sort by up votes, downloads, comments, popularity by day, month, and year is also a big piece of UX importance.
• I believe the best front end implementation of this would be like tags, via URL, so the user would visibly see /printables/upvotes/, /printables/downloads/, etcetera.

// // Printable Viewing

• [x] Need to output an array of the printables thumbnails.
• [x] Need to output the 3d render into a shadowbox via button click.
• [x] Need to output the detailed information about the model (read me, files, additional text files, etc) into some kind of flexible format (to deal with java being disabled)
• [ ] Need to output comments
• [x] Need to output statistics (tags, total # of downloads, total # of comments, total # of up votes, date uploaded into English formatted variables that change semantically to quantity (i.e., 1 download, 200 downloads/1 up vote, 200 up votes)
• [x] Need to output download link for zip file for specific printable.
• [ ] Need to output author info (other work, 4 or 5) with thumbnail and name.

More observations to come. Please email me about even the smallest concerns/questions!

[traverseda]

It should automatically email you any comments.

[chrisdmacrae]

Perfect.

[traverseda]

@TristanTrim

How busy are you? We should figure out if/how we're going to split the workload. Nothing in particular looks too bad, but if you have a big chunk of time coming up it would be good to do another marathon.

[traverseda]

a discussion needs to be had about how to display categories to the users. Right now the implementation to display sorting doesn't support a straight-foward way to break-down into category.

You're the UX guy. As we've discussed, tristan and I would like to do this in a nice neon green on black. Any thoughts on the matter? I was thinking just have the first page of the pagination show the 8 most popular categories or something.

Alright. For the search we'll be using url parameters. So something like

mysite.tld/search/only=tag1,tag2,tag3&exclude=tag5,tag4&search=someterm

I'm not generally a big fan of url parameters, but it seems like this is one of the few cases where it's genuinely appropriate. (can I use csv in a url?)

With that set of parameters, I imagine that we could make our "printables" or "browse" page essentially a way to access the search. That's probably how I'll end up doing it in the backend. I don't know if the front-end should reflect that or not.

Our search system is really fucking powerful, and thus pretty complicated. It needs different configurations to work in production and in development, and bugs can arise when you switch between them. So it's a bitch to debug and work with. We may leave it until the end.

All of our files are hosted on a very fast/cheap CDN. That means it's difficult to keep track of number of downloads. It seems to me like the easiest way to do it would be to have the download link take you to a page on our site. That page then redirects/proxies to the actual file. We count how many times our download page got hit. What's the best way to do that? Any way to do it without annoying redirects?

There's also still a rather annoying and hard to find race condition in the thumbnail queuing system. Bleh.

English formatted variables that change semantically to quantity

That's something that's best solved with template tags.

{% if downloads > 1 %}
    downloads
{% else %}
    download
{% endif %}

Not that we couldn't do it in the view, but the templates are generally more understandable and easier to edit, so I like to offload functionality to them when it makes sense to.

Currently housed in a template with if/and statements. If this is the desired implementation, I will use this to import both the mobile navigation and desktop navigation.

I might be able to figure out something a bit more elegant, but it's good enough and I don't see any real drawbacks. Seems like the way to do it.

If you think doing the basic structure as imports instead of doing it as blocks makes more sense, then do that. Just one example. I might have structured it stupidly due to not being a web-dev. Basically, whatever template layer makes sense to you. I know the pages aren't named reasonably at least.

---

So yeah, I'm going to mostly be working on the printable viewing and the browse/search.

The printable view (you should rename it) should already have most of what you need. Do you want to start setting it up while I add the rest of the variables it needs? That and the basic block structure/menu stuff. We'll get to the browse/search later.

[chrisdmacrae]

I was thinking that the quickest and dirtiest solution is a drop down on the navigation. Not the most ideal, I know with time I could create more intuitive solution, but for the interim this will function and should make sense to the user.

That's perfect. This will let things inherit the tags between page changes and will make sense for power users who are GUI oriented. As for CSVs, I believe the browser will parse the commas to %2C. Gonna have to look into the best practises for URL search formatting.

As for the download tracking, I was thinking if one were to parse the logs for the file daily or hourly and pull the number of downloads from it, and output that to the page. That way it's clean and accurate. I'm honestly ball parking here, I don't know what CDN service you're running at launch and what kind of logging it does. Otherwise, a redirect is ugly and the best option is probably just tracking the clicks on that button.

Noted on the template based semantics, duh Chris.

Was just curious. I know down the road any kind of terminology change will have to be reflected site wide and having it pull that terminology from a variable for headers, navigation, and titles instead of updating static HTML would be easier for you guys in the long-run but harder in the interim.

Otherwise things are looking good. I'm working on a few semantics and have the printable overview about 50% done.

[traverseda]

Works for me.

We can use sed/awk to change terminology down the road. Don't worry about putting any extra effort into making it easy.

[traverseda]

If the same user downloads something twice, do we want it to count twice?

I just switched us over to the much more mature django-ratings (from django-updown) and was considering just having a second rating field, with only one option. It has a bunch of tools for making sure people don't vote twice (although for actual voting I presume we'll only allow logged-in users) and we can just use it.

So now /project/$PK/rate/0 will downvote and /project/$PK/rate/1 will upvote.

So basically the download count would be an instance of ratingfield that allows anonymous voting. It would only store whether someone has voted or not.

The problem with pulling from the logs is that it would create a dependency on a particular webserver/fileserver. There's not really a clean way to do it with my preferred cloud file service. And if we ever wanted to branch out to a different provider we'd need to rewrite a bunch of code.

I might add log parsing anyway, but having a server agnostic fallback option would be good. Ratingfield and presumably some javascript seems like the way to go to me.

[traverseda]

So we're still missing the "output author info (other work, 4 or 5) with thumbnail and name" and the download count. I'm going to be digging into the documentation on haystack search, since that's probably what we want to use to deliver all the author info. Search continues to be complicated and somewhat poorly documented.

This shouldn't affect what you're doing at all, but I added a new method to the project model. Now calling project.enf_consistency() will make sure the project has a proper thumbnail and a readme file. Otherwise it will set the project to be a draft. it returns true if the project does have a thumbnail and readme.

I also cleaned up a few bugs that would hurt scaling, and made it check to make sure everything's okay at a few different points. It should be harder to take it down through developer screw-ups or users managing to delete things they shouldn't be able to delete.

[chrisdmacrae]

We only want to count unique downloads. Otherwise we'll open the potential for an abuse of statistics.

This sounds good though. It's kind of unfortunate something as important as search is poorly documented.

I'm done of the print overview template. I need to make some changes to the navigation and mobile navigation and then I'll commit it to my fork.

On Thu, Mar 13, 2014 at 6:16 AM, traverseda notifications@github.comwrote:

If the same user downloads something twice, do we want it to count twice?

I just switched us over to the much more mature django-ratings (from django-updown) and was considering just having a second rating field, with only one option. It has a bunch of tools for making sure people don't vote twice (although for actual voting I presume we'll only allow logged-in users) and we can just use it.

So basically the download count would be an instance of ratingfield that allows anonymous voting. It would only store whether someone has voted or not.

— Reply to this email directly or view it on GitHubhttps://github.com/Rhombik/rhombik-object-repository/issues/25#issuecomment-37512641 .

[traverseda]

It's not so much poorly documented, as it is dense and lacking in high-level overviews.

Also, there's not native support for something like tags. I'm having to hack something together using multivalue fields.

But glad to hear it. I've been doing a bit of work sorting out the edit/upload system. It's a bit of a mess.

[traverseda]

search tentatively works at http://localhost:8000/search/ , but doesn't work very well yet. No advanced filtering and I'm having a hard time getting it to search through all the various text files.

[traverseda]

Alright. That's basic search actually working.

Now I need to

• [x] Set up infrastructure for customizing the search view/forms/querysets
• [x] filter results based on tags (hack something together using multi-value fields)
• [x] Implement some kind of upvote/downvote filtering. Decent overview of the problem space here. (may need to use rawqueries, or monkeypatch the ratingfield class to precompute the confidence interval and store it in the database on every vote).
• [ ] Hook search back into out queue system (haystack-celery is annoying, easier to just roll my own).

Should I try and include comments in the searchable text? That might have some weird results.

Is there anything I should be doing before I start tackling the advanced search/tagging stuff?

[chrisdmacrae]

Not that I can think of in particular.

It would be nice to standardize the sections of the site into their own templature for accessibility. I’ve done a little reading into how URLs, views, and templates are structured and it would be nice to compartmentalize areas into their own folders and templates.

That’s me being pedantic however, I don’t think it’s a huge priority until the system gets released for download.

[traverseda]

Pedantic is good. Right now it's all pretty loosely connected. It's pretty easy to change what template a view sends its data to. If you feel like reorganizing, I can move things over or show you how to do it.

God know the naming convention for templates is bloody awful. It's on my todo list.

[chrisdmacrae]

Currently I’m thinking a global organizational template structure that every other section gets dropped into.

I think I understand that views specify the templates they write to, and url.py defines the url structure that is generated by the server.

But I don’t quite understand the process of taking like views and pulling them into their own directory etc, kind of makes me nervous of breaking things.

I’ll take a proper think of the hierarchy involved and get back to you on that.

As for the committing to git. When I finish the printable overview today, I’ve created an upstream branch of the master repo that I fetch and merge into the local copy of my fork. Committing to my fork won’t effect the master repository, correct?

[traverseda]

You don't have write permission on the master repository. Seemed like the safest way to do it.

Nothing you can do with git will screw up our stuff, and on git pretty much every change is reversible.

You need to do a commit (to commit the changes to your local repository, the one on your computer) and push to your github fork (send the data to the chridmacrae/rhombik-object-repository on github).

So from a command line it would be

git commit -a #Write out a message detailing what you changed, and commit the changes to your local repository
git push https://github.com/chrisdmacrae/rhombik-object-repository.git #Send the local repository to github

[traverseda]

Alright, we can now filter based on tag. Took way longer then it probably should have.

the syntax is "/search/&tags=$SOMESTRING" where $SOMESTRING is anything format from this page.

There are a couple of other search options. I'll probably add a bunch of them. Feel free to ignore them in the UX though. /search/ will show the full list of options.

---

I presume we're going to want to use some kind of tag autosuggest for the filtering. There a bunch of different tools for doing that. Is there any particular javascript library you like to use?

What I've got right now uses jquery-autosuggest, you can see the example css here.

The search template is here.

[traverseda]

If you wanted to move or rename a template file, you'd do something like this.

Look in the urls.py to find out what view a url sends data to. Then you'd look at that view. In that view there's a return "return render_to_response('list.html', someotherstuff)".

Change list.html (or whatever it happens to be) to the path/name of the template.

The views are already organized more or less based on what makes sense. From a back end perspective anyway. The templates, not so much.

[traverseda]

So we have two different ways of viewing a list of projects. There's the thumbnail view, and there's the list view.

I'm thinking the best way to deal with that is in the template. We'd store a variable in the users session specifying how they'd like to view projects everywhere where you view a list of projects. Not counting specific cases like the "author info (other work, 4 or 5) with thumbnail and name".

[chrisdmacrae]

Everything is looking good so far. You guys are absolute supermen with the level of development you’ve been doing.

As for the list vs thumbnails, I agree that have a session to store state is the correct method. I think in this case with the floating toggle it will be very intuitive to call it a global toggle and let people switch on the fly.

An aside, when I merge the upstream and master I need to flush and re-set the database. Doing this has been causing issues each time where it seems to be only truncating or dropping part of the database and then syncdb won’t run at all. What’s the proper method with django to do this?

[traverseda]

You guys are absolute supermen with the level of development you’ve been doing.

Just me. Tristan if failing calculus, so he's not available to do much with the code base. Being completely unemployed helps.

Generally debugging goes a lot easier if you post the errors/output from the terminal.

But for the development environment if you have any issues at all with the database the proper method is to delete exampleSettings.sqlite, and then run syncdb and re-add any test data.

In production where we need to actually keep the data it's a bit different, but in development you can just trash the database and build a new one.

If you're having the problem I think just delete the database and run syncdb. If that doesn't fix it then post the terminal output from a syndb command.

[chrisdmacrae]

Some notes on the homepage to get it working and pushed:

I currently have the display working. I don't have any advertisements, or a footer printing to the homepage as-is because it would be better footer to be generated from its own template.

I need to generate thumbnails that are 4:3 and at a resolution of 281x211 or higher for the gallery display (or 300x225 to make it clean).

I also need to print the author's username and avatar (preferably a tiny thumbnail, 35x35) to the page.

Once we have upvotes going as well as download counts and comments, those will need to be printed too!

Cheers.

[traverseda]

Alright. Tristans free from school and up here in windsor to work on this. So we should be able to get most of this done in the next week and a bit. And make the whole thing a bit more readable and stable.

I'm going to start a new bug for managing what we're going this week. Prioritization and stuff.

This works like a wiki, but only emails you the first draft. Here's the link to the topic itself. We'll be treating it like a wiki mostly. I'll let you know if there's anything in particular you need to worry about though.