I just finished the basket and pushed it to production last night. Now users can place items from their inbox that don’t belong in a particular patch or quilt into the basket. Because the basket is expected to contain a lot of content, I added a more advanced way to find content within it. When a scrap is added to the basket, the source html of that scrap is parsed server side and the meta content keywords are used to tag the scrap. Typing in the basket’s search bar makes asynchronous requests and renders the scraps with tags matching what is being typed. In the future, I will implement a more advanced scrape of the scrap’s source page to get additional relevant terms.
As mentioned in an earlier post we have run into some difficulties with our bookmarklet because it displayed the add button as an iframe with query parameters passed through the source uri. This worked well except for server limitations on the length of the uri, which prevented large chunks of embed code (such as youtube videos) from being collected. We have now fixed this problem so that embed content, no matter the size, can be collected. On mouse over of compatible content, an empty iframe is created. An invisible form is also created with the embed code for the moused over content and the current url that posts to an endpoint in our application. This endpoint returns the html of the send to unu button with the embed code and source url as paramaters. However, the form identifies the empty iframe as the target so that the returned html is rendered in that iframe rather than in the main browser window. When the user clicks the button rendered in the iframe, a new inbox scrap is created.
After, removing the CSRF protection for the add button resource, the bookmarklet now works on embedded content of any size. Additional modifications to the bookmarklet allow users to capture text by highlighting it after hitting “enable unu,” generating an add button as usual next to the selected text. We haven’t pushed these changes as there are a few minor tweaks we still want to make, but soon our users will no longer have the disappointment of seeing a 404 error when mousing over youtube videos.
Thanks to Sasha, who got the backend working for those two elements.
Initial profile page implementation also complete; it actually contains the entire contents of the Friends tab, so we’ll need to decide what’s going to happen to the Friends tab.
Coming up: backend for Quilts, Basket, and Profile.
If we manage to finish those backend elements, I’ll look into popup fragments that allow us to delete or organize scraps after clicking.
Exactly what the title says. Unfortunately, it’s not very exciting. I wrote up some support for user icons, but for some reason the emulator stops loading them when I add more than 3 to a page. Anyway, unu doesn’t have user icons yet, but I guess that code might be useful in the future.
I believe that I have finished my UI components now, pending user feedback. But for that we need backend. I could also implement a popup that allows the user to delete or move content, but I think it’d be wiser to wait for the backend to catch up first.
Thanks to Sasha, the backend for the login is complete. As in …we can log in. Yaaaay.
Here’s the unu login screen.
Not very exciting. Here’s some cool stuff– scrollable tabs! We noticed that after adding the browser tab, things became squished😦. And if we add the friends tab, things will become even more squished.
So here’s the scrollable tabs. You’ll notice that I made each tab bigger to make it more finger-friendly. It was a bit of a pain to make the tab bar fill the screen still upon orientation changes, but I think I succeeded.
Unfortunately, I have no idea how this will look on a tablet, and I have no way to test it.
My next project will be the Friends tab, and after that it’ll be UI testing (after we get a backend so we can actually load user data..)
Once the button is clicked, the embed code is posted to unu where a new scrap is placed in the user’s inbox. The troublesome part is actually getting the content into the iframe. Currently we do this by passing that content as query parameters on the iframe’s source URI. The problem with this is that some of the embed code is quite lengthy and many servers (as well as browsers) have a limit on how many characters a URI can have. As a result, under the current method, content such as videos on youtube end up needing a URI that is too long and so can not be brought in to unu through the bookmarklet.
One fix we thought of was to instead pass the xpath or css path of the particular object (which is much shorter than the embed code of the object) and use an HTML parser on the server to extract the relevant content. We quickly realized that this approach can not work because many pages are dynamic and will not have a certain element (like the one the user is trying to collect) until after that user has interacted with the site in some way that is irreproducible on the server. Additionally sites that require logging in would prevent an HTML parser from getting the appropriate content.
One last approach is to post the embed code to the server and get back HTML that, when put in an iframe, creates the same button as in our current method but has no restrictions on the length of the content (since posted data does not have any size restrictions). The problem we encounter with this is that ajax prohibits cross domain posting.
We are constantly looking at ways to improve the bookmarklet so that it is as flexible as possible and is compatible with as broad a variety of content as possible. The strength of unu is in collecting media of all different kinds in a single place where it can be meaningfully organized and arranged by users and a big part of making this a reality lies in having a properly functioning bookmarklet.