Have you attended an online call with Public Lab? We'd love your feedback!

Public Lab Research note

GSoC Update: Week 1

by xvidun | May 28, 2014 22:47 28 May 22:47 | #10516 | #10516

Progress:

For the past week I've been working on improving the upload interface for Mapknitter image upload. This is the weekly update on work that has been done.

Working git branch:UIModelling

  • Implemented multiple image upload with drag-drop feature. Implemented JSON response from the controllers to work asynchronously with the file upload plugin.
  • Integrated a basic file upload interface based on blueimp's demo of basic plus UI using it as a major reference. Have to work on bringing a cleaner interface in the coming weeks.

As of now I do not have a remote server to push my work for preview. Jeff said something about providing remote derver to GSoC students which if provided I can push to, otherwise I can try hosting on heroku or openshift.

Preview:

gsoc1_5.png

gsoc1_4.png

gsoc1_2.png

Incomplete tasks:

  • As you can see the interface is really dirty, I will have to work on designing a cleaner interface.
  • The interface used is not very relevant for Mapknitter, function to delete directly from interface are not yet worked on. Some redesigning of the UI has to be done, which I would definitely need help on.
  • Although the upload works smoothly, the relevant callbacks has not yet been made, tried working on it and I'm having issues doing it from the current upload Iframe. Also integration with Anish's project has to be done.
  • Client side validation has not yet been worked on - will not be difficult using the plugins validation functions. Currently validation works interactively with failure response from server.
  • There are some file-upload dependencies that have to be removed and make it lighter.

Experiences:

  • Although jquery-fileupload by Blueimp used here is a great plugin implementing it was a real hassle while taking it longer than expected to understand and implement.
  • The plugin lacks good documentation so I had to use other sources to figure things out. Although I could not use the jquery-fileupload gem for lack of support for version 2.3.15, it was a great resource to understanding to implement the plugin in a rails context.

This has been a great week with most of the major work on the schedule done and looking forward to another good week with Public Lab and GSoC.

10 Comments

  
mathew commented over 5 years ago

Nice Vidun! I'm glad to see that the majority of the functionality is in there.

Reply to this comment...


  
warren commented over 5 years ago

Yeah very nice -- for interfaces, think minimalist! Can we have the upload begin automatically, and not require a "start" button? Also, perhaps you could use the Bootstrap modal instead of the old one there: http://getbootstrap.com/2.3.2/javascript.html#modals

We'll get you a VM soon - if you want to try Heroku, go for it, though.

Also, what do you think of just allowing people to drag images onto the map itself, to start uploading them?

I'm making a set of Github issues for you based on this feedback.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


  
warren commented over 5 years ago

https://github.com/publiclab/mapknitter/issues?labels=gsoc&page=1&state=open

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


  
warren commented over 5 years ago

Feel free to make your own issues to help you manage your time and planning!

Reply to this comment...


  
xvidun commented over 5 years ago

for interfaces, think minimalist!

The current interface is based on Blueimp's demo. I just wanted to get everything working.

Now that everything is working I can start designing the interface for mapknitter. I'm having discussions with my mentors regarding this, hopefully we'll bring up something great.

There is a lot of work to be done!!

Reply to this comment...


  
mathew commented over 5 years ago

cfastie, xvidun, and myself had a little talk about interfaces. I'm going to go the opposite of Jeff's minimalist suggestion here and suggest that we stick with a file management pallette. the idea is to have a place to: manage image order choose between automatic image order or manual image order choose between auto placement or manual placement highlight images by name (click on name, highlight image, click on image, highlight name.) upload in the background manage images for annotations

annotations.png

Reply to this comment...


  
warren commented over 5 years ago

This sketch looks good - by minimal i meant we can use just a "trash" icon for deletion, and skip buttons like "Start Upload" by just auto-starting upload on drop. Progress bar and cancel upload can just be a spinner instead of a bar and a cancel link. Just thinking about pixel real estate.

A built-in sidebar could save some extra pixel space too and may be easier than a "dropdown" for showing a long list.

Another thing is that as we transition to just showing all images for your viewport, rather than having people create a map which "contains" images, the list of images may just be those currently shown in your viewport, which could update whenever you move the viewport. This does complicate ordering (which then has to be ordered in relation to any nearby image... the order index numbering would have to contain all images globally in MapKnitter), but we can probably put off thinking too hard about that for the time being since I don't think we have someone working on ordering. Perhaps at that time, we'd allow you to order upon assembling a set of images to export, and store just local (not global) order in the Export record. Or, we could (gasp) use decimals for order, and just allow images to be ordered with near-infinite precision, never having to "run out of integers" when ordering, the way CSS breaks down. Perhaps we could use a rough starting order # based on extent, which maps global size to some initial order decimal.

Having a clear "Drop files here" region doesn't conflict with allowing drag/drop anywhere on the window; it's a good idea to have a specific callout even if more advanced users know you can drag anywhere. When you drag over the whole screen, a fat dotted line and transparent overlay with "Drag images here to start uploading" should appear over the screen in a style which matches the dotted line around the dedicated drag/drop region.

I like the show/hide toggle for each image! Also, perhaps there'd be an auto-place button on each image. At first, as it's being tested, this could be under a caret menu similar to the like/follow menu on PublicLab.org research notes. Tucking more advanced (or more beta/prototype) features away can keep the interface less intimidating while making them available to more advanced users. Just a suggestion, though.

Reply to this comment...


  
mathew commented over 5 years ago

definitely agree re: no need for "start upload" button, and the the big drop zone with the dotted line. I wasn't imagining an exclusive dropzone, but that is what the sketch looked like. A sidebar might be better-- good thoughts on how we place this without eating too much real estate. I also am playing with the idea of a popout window. a "poppable" sidebar would be cool.

As we get into the map annotations with embedded pictures/notes/audio, some sort of file management zone seems to become important. Maybe the map image zone isn't the place to play with that.

you'll have to sell me on the idea of only listing images in the current window area-- it sounds like a "bouncy" menu that will change as I move around the map and drive me kinda nuts with its rapid movement. I'm thinking of menus on phones that change between the time I think to touch them and when my finger gets there (think Google Maps suggestions). I understand that when people get to lots and lots of images in Mapknitter a "master list" may get a bit unwieldy. I think that can be manageable if the correspondence between image in map and image in list is maintained by highlighting images on the map when clicking on the list and vise versa.

Ordering is a big issue for me, and Chris echoed my thoughts. Would it be a big feature to manually order, since ordering is already a necessity? I want to do it while knitting. Its especially a problem in the existing mapknitter when I place an image with a small area then realize I want to place an image with a larger area to fill a hole in the map, but it will completely obscure the more detailed image placed first. Its super hard to match the two, because mapknitter usually puts the first placed image in the background. I find myself deleting the smaller image, placing the big one, and then re-placing the small image.
That said, the list doesn't have to manage ordering. A "bring image forward/back" control that can be used when working with an image would allow the sort of relativistic sorting you're talking about.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


  
xvidun commented over 5 years ago

The sketch looks beautiful! it just inspired me to make a dirty sketch of my own. As a lot of features will be coming up this summer it would be necessary to have a management tool in place of the regular upload interface. From the discussion I think I should start with implementing the features of image selection(and highlight selected image), show/hide toggle in the next iteration. Would displaying other info like locked, modified, etc(probably with a 'more' trigger on image to go with the minimal design) be necesssary?

I've bought up a minimal interface with auto upload and drag/drop. Would it be necessary to have an exclusive drop region? I'm not sure of the problem of using the entire map as the "drop zone", the novice users can however fallback to the traditional approach of selecting files/folders for upload.

I'm a little confused about ordering, how should I approach this problem. Is ordering necessary as in Mapknitter once a larger image is locked over a smaller image the smaller one is automatically layered to the top.

Is this a question? Click here to post it to the Questions page.

Reply to this comment...


  
mathew commented over 5 years ago

I think image selection and show/hide toggles are a good starting point. Other options could be in a dropdown menu as Jeff mention, maybe leave room for one more direct option like lock.

Using the whole map as a drop region is probably fine. I don't see the problem. good point on novice users.

The ordering issue does come up-- i don't always want to edit an image that automatically pops to the top-- sometimes I want to edit an image while it is below (selection currently brings it to the front) and the small/large image calculation is imperfect. I think its a case where user control is more straightforward than automatic placement.

Reply to this comment...


Login to comment.

Share

Public Lab is open for anyone and will always be free. By signing up you'll join a diverse group of community researchers and tap into a lot of grassroots expertise.

Sign up