Responsive ticking template page

[brendanheywood]

• [x] make sure all routes / shots / pitches JS is retained
• [x] clean up date picker and make native (check can select partial dates)
• [x] clean up date over ride
• [x] make 'with' also a global field like date
• [x] make 'trip' a global field or just remove?

[brendanheywood]

Rough mockup of reorganized ticking page

Simon one thing I've noticed myself and other is that if you add a bunch of ticks, and you could be bothered using the 'with' field, they are almost always the same, so I reckon this should have a default field like the date. I'd also like to change the semantics a little so that these two fields are defaults rather than overrides, this seems backward to me, ie you should say I did all these ticks on X with Y, and then add the exceptions to this against each tick.

[scd]

Looks nice.

The default date is an interesting one. The core problem is that date is prepopulated so the workflow does not work as a default without some javascript smarts. We could automatically clear all non-updated date entries after somebody has entered a default date.

Example workflow 1: 10 ticks yesterday

• enter default date, system automatically clears date for all 10 routes

Example workflow 2: 8 ticks yesterday, 2 today

• enter default date for yesterday, system automatically clears all dates
• enter today's date for two ticks

Example workflow 3: 9 ticks yesterday, one the day before.

• enter the dates of the tick from the two days ago
• enter the default date, and the system automatically clears the 9 tick dates for the unchanged ticks

With field works much better as default.

[brendanheywood]

There doesn't need to be any javascript for this to work (but there will be to make it nicer). The server will set the date in the default field to today, all other dates will be blank. If you change the default date you don't need to ever update any other dates, they stay blank. If you remove the default date and don't set specific dates for ascents then they won't have a date. After submit the server will figure it all out. I intend to put a little bit of JS in to copy the default date when changed into the placeholder attribute of the ascents date, that way you'll see a grey date if it is left as the default, or a black date if you've specified it.

[scd]

Let's just go with it and see if there are any problems. I don't want to put anything in your way from developing a smoother process.

[brendanheywood]

Ok so if you can implement the changes to get the default 'with' working and 'date' working the same way too, and then I'll tackle all the reshuffle work?

[scd]

For my benefit, server end task list:

• [x] default date should be set for multiple ticks
• [x] tick dates should be cleared for multiple ticks
• [x] if tick date set then use it
• [x] if tick date not set then use default
• [x] if tick with set then use it
• [x] if tick with not set then use default

[scd]

UI template notes: I have pushed the server bits to repo, although the with stuff is not fully tested. Some notes when implementing

• [x] there is a control variable 'assignTodaysDate' which controls whether or not to use the dates provided by the server or to use local time for the UI browser. The issue here is when ticking 'metoo' the work flow should take the server provided date, otherwise we want the default to be the local time of the browser.
• [x] need to be able to enter partial dates. To do this you have to disable the datepicker as it does not allow partial dates.
• [x] do we want a default tick type as well, see issue #1035 and #908
• [x] do we want a default trip field as well, see issue #999

[brendanheywood]

For dates, I'm just going to try and find a better date picker that can handle partial dates, there are a couple out there and I'm considering writing my own in my spare time (ha!). I'd like to experiment with this one: https://github.com/HaroldSHenry/aboutWhen

A default tick type I don't think is as high value as it's much more variable. I'm highly likely to tick 5 boulders in a day and they'd all have different types, where as the date and who I was with are almost always the same. When climbing sport, for me at least the same applies, I'd onsight lead something, and dog something else, top rope a third. For trad it seems similar as I'd lead half and second the other half, and its likely that each batch of ticks is smaller anyway. So I could go either way but opting for less clutter for something without a clear win.

For trips, personally I'd like to just scrap it. Happy to be vetoed but to me it's just a failed feature we need to deprecate. Also you shouldn't really ever need to select a trip anyway, it should be implied by the dates. Ie you could retrospectively add a trip and your old ticks when get added to it for free.

[brendanheywood]

Another date picker idea: http://www.jqueryscript.net/demo/Scrollable-jQuery-Date-Picker-Range-Selector-Continuous-Calendar/

This one made me think - when we say '2013' or '2013 Mar' what we're really staying is 'somewhere between '1st mar 2013 and 31 mar 2013'. Did you ever consider the internal dates being represented as a range instead of a partial date? I'd never thought of it, yet it seems so obvious to me now, very similar to the internal grade range system.

[scd]

Getting a better date picker would be fantastic, the one we have is missing some key concepts.

I don't want to do anything MySQL does not do with a single date. I don't think it is that important except for giving people the ability to back date ticks they cannot remember the exact date for. It's a real edge case, but we have to have it in otherwise you cannot back date old ticks, which means we would lose people. I don't think we have to do anything special with stats and facets, etc.

Lose trips and see who complains.

If we don't want to do default tick types then we should comment and close the other issue.

[scd]

BTW, the date range concept also meets Facebooks concept of having a start and finish.

[scd]

Brendan, I have removed the "Must be resolved for release" label. Please let me know if this is not ok for the release.

[brendanheywood]

All good

[brendanheywood]

My brain dump, and I think pretty well in priority / dependency order

bare minimum responsive

• [x] get rid of all hover styles. These are no 1 cause of janky scrolling on mobile
• [x] re-order the html to each label and input is together, and then make each field inline-block and let them flow (another general tip, avoid floats completely, inline-block is heaps easier to work with and never needs clearing or clearfix hacks) I've thrown together a minimal example here:

http://codepen.io/brendanheywood/pen/sAnzJ

Low hanging fruit (all ticks)

• [x] remove 'ascent label' override field
• [x] rename 'with' to 'Who with'
• [x] remove trip
• [x] remove red button to delete shot for the first shot (also give it a title="Remove shot")
• [x] remove 'with override' from shot IF there is only one shot

Bonus points for gyms:

Generally I think it's better for gyms if we can drastically reduce the number of options and force people into choosing the right tick type.

• [x] if gear style is 'top rope' and we are inside a gym then only show these options for ticks:
• [x] if gear style is 'sport' and we are inside a gym then only show these options:
• [x] if gear style is 'boulder' and we are inside a gym then only show these options:

(note this isn't changing how any stats are done, just purely cosmetic in the drop down - but it does highlight that we don't categorise boulder ticks very well)

Bonus points for single pitch / multi tick:

• [x] make 'with' field populate the placeholder attribute for each pitch (similar behaviour to date) (this it at two levels, 1 across all ticks, 2 across all pitches
• [ ] instead of a js alert if you remove the last pitch, this should be equivalent to turning off 'log pitch fields

[brendanheywood]

note I just saw a I mistakes in the 'sport' drop down, I've replaced it

[nicHoch]

Please do not remove the "Trip" field! I think that is a very useful way to categorize your ascents. Handle it like "date" and "with" in the "override" header.

[scd]

Thanks for letting me know you find trips useful. Not so many people use trips so it is at risk of being turned off.

[nicHoch]

Hm right maybe I use the trip not really in that way it was created for. I could live without trips if you add a possibility to add self defined tags to ascents instead. Tags would be the universal way to categorize (group) ascents. To filter your ascents list and also performance chart by that tags would be a very nice way to "data mine".

Nicky

[brendanheywood]

Nicky what if you could just enter any #hashtag or multiple #tags in the ascent and then filter on that? I think trips have some value but even if we keep them long term I'd prefer it if it was automatic, like say trip x is with people a,b & c, and to a place over set dates. Then any ticks inside those dates and place are automatically part of that trip without constantly repeating it when you tick stuff.

[nicHoch]

Free #hashtags are somehow nice and easy but it might not by consistent and performant enough. I have to remember the correct name of my #hashtags to add it into a comment and on the filterpage you have to know what to filter for.

Therefore I would like to propose:

• On the private admin page everybody can crate and alter a personal tag list.
• In the log ascent form you can add multiple tags to your ascent similar to the tag-UI for nodes ("sw" ,"limestone" ...)
• On the filterpage (logbook, perfomance chart) you can select multiple tags from you private list.
• If you can share a tag (unique id) with friends: you could emulate such things as trips.

Sounds like a lot of work. But it will bring some structure to the ascent data.

Nicky

[brendanheywood]

If we added tags using hash tags the performance would be exactly the same as we'd parse these out when you save the ascent, the data model would be the same. But can you flesh out a bit more all the various types of tags you might want to add? It seems to me in that list that things like 'sw' and 'limestone' and things that shouldn't be on the ascent at all but should be on the route and/or area, and we can already tag them. As a side note being able to quickly tag them in markdown (in an area, route or even ascent description) is on the list see #1252

We don't yet have exposed an easy way to search on these but that is coming (may even be implemented but not exposed)

Also if tags are missing from a route / area, and then they get added, all previous ascents will benefit from this without retro adding tags, so this seems far superior. The only thing that isn't covered by this is arbitrary tags, like #nickystriptofont which if we allow this in #1252 then I think this solves it well without any additional config needed. If we implement #1252 really well then you'll get a dropdown of the built in tags, and quite possibly tags that you have used before (and also friends?) which also solves the problem of remembering the tag name.

Anything that requires prior configuration seems like a barrier to adoption, and the #hash tag metaphor is already well established pretty well everywhere else so I think most people would pick it up pretty quickly.

[nicHoch]

Yes for sure: tags like 'sw' and 'limestone' should be attached to routes. If an ascents knows about this tags from the route (even if later added): very good that really opens the door to questions like: "Do I climb better (harder, more onsight ...) in limestone or granite?"

To create a tag on the fly with the #hashtag metaphor: very good To have a list of available (autocompletion..) tag: in my point of view very necessary

Tags for ascents that I have in mind are:

nickysTripToFont2013

 #afterWorkClimbing
 #trainingSessionInLocalCrag
 #WeekendTrip
 #Vacation
 #WithAlpineClubXY
 #guidedTour
 #...

We should think about that the tags might not necessary added to a ascents only via the comment field. Not that a tag is top secret but most likely uninteresting for everybody to see.

Nicky

[scd]

Some of these might fit into the concept of circuits (will be rehashed as a list of routes). On Jun 13, 2014 6:31 PM, "nicHoch" notifications@github.com wrote:

Yes for sure: tags like 'sw' and 'limestone' should be attached to routes. If an ascents knows about this tags from the route (even if later added): very good that really opens the door to questions like: "Do I climb better (harder, more onsight ...) in limestone or granite?"

To create a tag on the fly with the #hashtag metaphor: very good To have a list of available (autocompletion..) tag: in my point of view very necessary

Tags for ascents that I have in mind are:

nickysTripToFont2013

afterWorkClimbing

trainingSessionInLocalCrag

WeekendTrip

Vacation

WithAlpineClubXY

guidedTour

...

We should think about that the tags might not necessary added to a ascents only via the comment field. Not that a tag is top secret but most likely uninteresting for everybody to see.

Nicky

— Reply to this email directly or view it on GitHub https://github.com/theCrag/website/issues/1222#issuecomment-45987569.

[scd]

I have been thinking about the tagging above. This might be #easy because there is just a small bit of server code and virtually no UI management to get something implemented. It may only be a couple of hours work. Here is my task list:

• [x] create a simple tag table: id, tag name.
• [x] create a tag association table: id, tagID, entityID
• [x] when creating an ascent parse ascent comments, when #tag appears, create the tag if it is not in the database, create the tag association, and also associate the tag with your account
• [x] when updating an ascent parse ascent comments, remove associations if a #tag has been removed from the comments, otherwise add the #tag comments if they are missing from the association
• [x] In ascent faceted search add a filter for tag id or name
• [x] In ascent faceted search filter list add a list of tags to checkbox filter that you have associated with your account.
• [x] Add a search input box for specific tag name

Bonus points:

• [ ] do the same for forums, areas, routes and photos. Note that if we do the above correctly this should only be 20 minutes work for each. This means the tag association has to link to a generic ID, not an ascent (because IDs are unique across the whole system this will not be a problem). Make sure we write the ascent server code as a function so it just becomes a simple matter of calling the same function when saving messages, routes, areas and photos.
• [ ] write an article

[scd]

BTW, I have started playing around with ascent logging page. One thing I want to do is to filter out some of the ascent styles for gyms. I think we need more top rope tick types for gyms. Chris wants to distinguish between the equivalent of flash and clean ascent. I think we need to put in a Top Rope Flash tick type. (Actually there is duplication in tick types, so we probably need to rethink the whole tick types concept, but that is for another day).

[scd]

Progress in responsive ticking:

• [x] removed tables, replace with inline-block
• [x] created wrapper divs for javascript
• [x] moved css & javascript to file
• [x] disabled pitch info for small screens as it is too busy for a hardly used function (plus problems getting it working reliably on a mobile)
• [x] trips disabled, pending the hash tagging being implemented
• [x] multiple route ticking available on all devices
• [x] multiple shot ticking available on all devices
• [x] logging pitches only available on large screen devices
• [x] datepicker does not work for my mobile - do we need another.
• [x] gym label colors override grade band colors
• [x] I have currently enabled all process pages as responsive - could be dangerous, so I think I need to just enable the ascent logging
• [x] add a Top Rope Flash tick type
• [x] restrict Gym tick types
• [ ] how to handle the long list of grades if no grade is provided - see #1500
• [ ] in gyms we should restrict the grades to the grading system of the grade of the route (in otherwords if the route is a ewbanks grade 10 then the user will only be able to change it to another ewbanks grade.
• [x] heurestic to enable multipitch.
• [x] update ascent should be responsive
• [x] hash tagging
• [ ] Fast tick from list view using today's date - not going to do as I think the new form is pretty good.

BTW, I had difficulties with media responsive stuff. In particular checkbox sizing. I think there are many overlapping issues, including probably a precedence issue with our css (should the responsive.css be loaded after other css resources?). Anyway the easy solution ended up being to always make the comment field the optimal size for mobiles.

[brendanheywood]

While css resource order does matter, in general it shouldn't and you probably have selector issues instead. If you can give me an exact example I can take a look. Often the culprit is using a mix of id's vs classes, as the id's have much higher precedence.

[scd]

I used exactly the same selector, hoping it would override for smaller screen sizes, but then I realised that the responsive code is loaded before the logascent css. In the end I made a policy decision that does not look too bad, so I am ok with the comments not being too wide. So don't worry about it unless you think it needs to be changed after reviewing what I have done. The comment boxes can be manually resized anyway.

I find css so frustrating, little issues can take ages to resolve.

What is now bugging me more is the datepicker not working on mobiles. I will have to do some research tomorrow. It has to work for mobiles and it has to work for partial dates.

[brendanheywood]

I do 95% of my css dev inside chrome dev tool with live preview, and then copy it back to the less files compile and retest. It shows you exactly what rules are applied, in what order, and if something isn't applied it is really easy to see why not.

Also a really quick solution to this general class of issues is to change:

.some.class {}

into

.responsive .some.class {}

The .responsive class is added to the body tag by minor/headTag

You are probably over thinking the datepicker. If someone is on mobile just use the built in html5 type="date" and let the phone do what it does best. You can detect support for this and just never load the date picker at all if the browser supports this: http://stackoverflow.com/questions/10193294/how-can-i-tell-if-a-browser-supports-input-type-date

The only downside to this is the html5 date format may be slightly different, we should just roll with this and change the backend to support it, and update the format the jquery datepicker uses when it is loaded to use the same format too. So think of the jquery datepicker as a fallback implementation of the html5 date type. Note that this means that some desktop browsers will also have native date pickers, and this is just fine.

Then if the field is unlocked swap it's type back to text and let them type it in manually.

To get the conditional library loading just do a dirty document.write(' Githubissues.

Githubissues is a development platform for aggregating issues.