jkoudys / janeswalk-web Goto Github PK

It's way more important that people see their login details than, eg., the 'about' pages. Those pages are linked from the footer and many articles or more natural places to look (eg the planned updates the profile page.)

The login menu shouldn't disappear when you're on a smaller window -- the nav should.

Add to bottom of onboarding form (add my city), and the join JW.

Has all walks on one page (no tabs or "See all walks")

Maybe look at infinite scroll instead of splitting the types

When any page is updated, an event can be configured to fire by setting config/site_events.php like so:

Events::extendPageType('walk', 'on_page_update');

The controller for that page type then needs an on_page_update() method. We should use this to clear out all walk-related caching whenever a walk is updated, which should include:

• A cached model object for Walk
• Cached XML of the walk-card

After I am prompted to log in because I click 'Create A Walk' from the city page before signing in, I go through the sequence and end up on my profile page. This is pretty frustrating because I expect it to go directly to the walk creation (or whatever I was last doing).

I think this can be fixed by ensuring that the param rcID (referral collection ID) is set correctly in the login menu.

My biggest complaint about bootstrap has been how it encourages building giant rats-nests of DIVs, filled with piles of classes. This is a huge step backwards, all the way back to the web 1.0 days where your HTML was responsible for both content and layout, since you're doing all your layout in classes.

A much better approach, which will help with long-term maintenance, but not require nearly as much work as removing bootstrap entirely, is to simply use the bootstrap sass mixins instead of these classes. With this approach, instead of bootstrap forcing us to have unmaintainable, ugly HTML, we can keep our HTML as only defining content like it's supposed to, but also use bootstrap to simplify our SASS too.

This will be especially important after moving to 5.7 and switching to a proper templating system, since then we can take a more compositional approach to templating, with our templates defining the content's structure. A big place I see this being useful is for walk listings -- walk cards on the city page could easily be formatted differently than when you embed walk links on blog posts, for example.

ref:
http://getbootstrap.com/css/#grid-less

The alignment on the walk cards still breaks occasionally, especially when in the responsive media other than really-wide or really-skinny.

Now that the ThemeHelper is static and no longer contains images, it should be quite a bit easier to take out all the leftover <i class="icon-*" syntax left over from the fontawesome 3 days.

FA4 is generally a lot cleaner to select on (either in DOM or css) since we don't need to match icon-* as a pattern, which was clever but more complex than simply saying class="fa" to match fontawesome as we can now.

We also spend quite a bit of time looking through the icon set every time we need a new icon for anything (themes especially), so it will pay off the next time we have to add an icon since v4 introduces quite a few cool new ones (esp. http://fontawesome.io/icon/pied-piper-alt/ )

On the registration page, if your home city isn't there, give the option to add a new city.

Also include a radio button to become a city organizer.

One hole in the map creator interface is that there's no way to edit the order of the stops. You can create a bunch of points in order, but looking at how this is displayed on the walk screen this order is quite important. There should be little arrows or something on each stop in the list below the map, so you can say what order the stops are in.

All the CO related questions in typeforms should be tied to user attributes

• was this your first year as a city organizer
• do you think you will organize JW next year

The random 9 card preview of walks on the city-page is currently rendered server-side, which means we won't get random cards should full-page caching be enabled. Even at the height of a festival, that's only ~160 walks max for a city, so it should be easy to render all that HTML, especially if we cache it. Just make sure the CSS is set to make the preview thumbnails background-image:none !important; when it's one of the hidden ones, so it doesn't load all their thumbnails and bog down the browser with that.

Perhaps the whole 'show all walks' thing shouldn't be a separate page, just some js that changes the interface to show the tabs.

In the walk card, if there is no Walk Leader, sub for Walk Organizer.

Fatal error: Call to protected method WalkPageTypeController::getJson() from context 'WalkFormController' in /home/alison/work/janes-walk/controllers/walk/form.php on line 80

There's some added jankiness since putting in #12 - this should fade out the old content, slide the area to the left, then fade in the complete listing. Bootstrap ought to have a nice way to do this, but I'm not seeing one immediately, and for some reason even though my elements 'fade' out, they show up as soon as I try to slide the width left.

Notify admins if a CO is about to expire.

We're long overdue for having at least a basic test suite implemented. Get PHPUnit setup and create simple tests to make sure that one page of each type can be loaded without exceptions. There are plenty of other tests to be written that can go into new issues.

Right now, gettexting the php (and soon, xsl) for the .po file is run by hand. This should be a grunt task - make a new .po, and build .mos from the various language pos.

Fatal error: Class 'JanesWalkController' not found in /home/alison/work/janes-walk/controllers/page_types/blog_entry.php on line 5

When a new city page is created, or its coordinates/title updated, clear the world map cache as it is now out of sync.

Create a job to export all users who own walk page in a specific city, and all associated community voices and volunteers - so that we can thank them in the annual report

Add a tooltip here to say you can click the profile name. Text on this page should read: Welcome to our global community! We're so glad you joined the constellation of incredible citizen urbanists that make their cities better every day, by walking and prompting open discussion with their neighbours. Let's get started .
//I will add more later. But for now, keep brief//

dependencies: #17 #13
Testcase:

• curl the cities currently listed in map
• Create a new city
• curl the map, validate city exists in it

It's an old idea, but the more I play with golang, the more I think having a template in anything other than a static file is just asking for trouble -- especially in an MVC. c5 has suffered in the past from way too much control logic around its views. Try setting up some simple blocks as XML. Eventually the whole thing could be rendered as an XML tree, which means 0% chance of invalid HTML and some interesting fragment-caching too. XHP on my hack-based sites has been great, but if we can't use inline XML syntax, just use a separate xml file.

I was a bit worried about using XSLTProcessor, as it wasn't available on my default ubuntu php install, but it just took a quick sudo apt-get install php5-xsl. All the shared-hosts I've checked (inmotion, site5, godaddy $3/mo plan) include XSLTProcessor.

Link to a new page's content.

Registration should only have attributes which are required asked for. We have the nice profile page now which prompts them to complete their profile, so we could ask all those questions then. To get their account setup asap, they should only input firstname, lastname, home city. Done.

The remaining fields that display on the profile page should be prompted for on the profile page. Let's add 'do you want to return as a city organizer', and questions about their commitment to the festival, yearround, etc.

Can CO names appearing in blog posts always become links to their profiles?
Would this be done through typeahead/autocomplete in composer when user names or city names are recognized? This would significantly increase internal cross-linking for janeswalk.org.

Once we have the new bootstrap/templating all migrated, move up the property so COs can list their commitment dates on here.

We'll want something like this for tracking when COs want to be active, when walk leaders want to return, etc.

Either using the base c5 Cache class, or do in-memory key-value caching with MyDis, of the walk model objects. Now that this is a model, it should be quite quick to serialize/deserialize from cache as a whole, which should speed the walk page load time up significantly.

We need a media query for max-height, and set the #progress-panel position:absolute;padding:0; when the window's too short, so the save button doesn't disappear for people.

For Nadia/Denise to use on backend to find who is already involved and may want to be a CO.

2 features here, so may need to break this out into separate issues, but base control function needed for:

• Transfer a walk on the CO dashboard
• An 'assign as walk owner' button on the 'create a walk' form. Might also need a 'create user' button (or just automatically do that).

The iframe was only included to keep behaviour close to c5 defaults. Now that there's a better MVC around the walks, the controller can be given a new method which takes image upload streams. Having the iframe for uploads has been a major css annoyance.

Keep in mind we may want to support multi-file upload with this soon.

good resource: https://hacks.mozilla.org/2011/03/the-shortest-image-uploader-ever/

To make the Walk model class more MVC, let's follow the Rails-ish pattern and include a save() method, which persists the current state of the model to the DB. Right now, it's setting those attributes directly from the JSON, mostly as a results of copypasta from the old fat-controller. Instead, it the model should be updated directly and saved. This way, you can directly update the model properties too, then call save. This is also a good way to keep things transactional.

These needs a warning - you can click 'next' without saving anything (not clicking 'add date'). The 'add date' button is really prominent already, and exactly where you'd naturally read next when filling it out, but about 1 in 20 seem to be forgetting it's there.

Before publishing, we should check and add to the message to say 'no date set. You may need to click "Add Date"'.

This one's simple enough to do - the team icons are set as background images on hover. It won't load until you hover. Instead of getting the nice quick animation, the image on the 'build your team' page icon set will disappear while the animated one loads.

There are a bunch of ways to do this, but I think a :before/:after invisible pseudoclass would be the most robust, as it's a quick addition to the sass and should cover all of our browsers (individual browser rules can be rather finnicky about which CSS images to load, and building a whole attribute just to preload is a very 2006 way of approaching this problem.)

I'm thinking something like

.someButton {
&:hover, &:before {
background-image:url('/path/to/image');
}
&:before {
display:none;
}

should probably work. If the image won't load on some browsers since it's on a display:none, then visibility:hidden; z-index:-1; will probably do the trick.

When the typeform for adding a city is created, setup the user identified by that email as the CO of the city. Create the new city as a blank city, with all the info they've supplied.

JanesWalk\Libraries\MirrorWalk;

Evaluating options for other types of registration: meetup, uniiverse, facebook, etc - would it be easy to have the walk leader select from a couple event registration third party sites?

Does Facebook give us email, first name, last name? If not, it's not worth it.

Clean up UX - make it beautiful

Write a dashboard widget that returns all city organizers for a specified date range.

It feels like a bit of a step backwards, but they're really not that different. While less lacks the if/else/for/etc. of scss, I'm starting to think those are bad concepts to use for a css preprocessor anyway, which ought to perform more like a templating engine, and act more compositionally than like a scripting language.

Whatever my opinions are on either (and I still like scss better, mostly because I'm more used to it), concrete 5.7 has introduced native support for .less, so you can link less files directly instead of having to compile as a separate step. This is way more powerful than it sounds, since it's much more than just a convenience: it lets you directly set less variables from php, which is how the system now works to customize themes.

I'm also trying to be rid of all that bootstrap-class awfulness. Twitter Bootstrap looks really good and is well tested, but those classes make for some ugly HTML. They release official less support, while scss support is 3rd-party, so if I'm doing the work in #27 already, it would make sense to move to less at the same time.

Also, LESS as a name is asinine. I might as well call a tool rm-rf. pfft.

One gets created for every point in the KML route. Functionally this doesn't do much, as a marker with no coordinates or title is essentially invisible when shown by Google, but as some of these routes may have 100+ turns in them, that adds significantly to the time to load + render the map.

We have a whole bunch of .js files strewn about now, which are always all loaded together. Look at using gruntjs (or similar, if there's a better fit for PHP projects) to uglify and merge all these together.

If grunt's set up, there's more that could handle too, e.g. compass builds (though I wouldn't mind dropping compass and just using plain scss).

Concrete5.7 is adopting the php-fig code style standards; We've been pretty inconsistent about style, so let's pick this standard (also used by symfony2, zend-framework, doctrine, and composer -- all c5-used packages) and stick with it. Goodbye nice, compact 2-space indents, hello more-commonly-used 4-space indents.

Wysihtml5's okay, but since moving to fontawesome4, none of its icons match, and the lib's last release was 0.3.0 (which we've been on for over a year) and the last update in their github repo was nearly 2 years ago, so I don't expect it to be updated soon. It's also occasionally getting confused by the HTML it has loaded, hitting an exception and losing the formatting.

tinyMCE is used extensively by concrete5, and there's a built-in helper for making a 'textarea' attribute edit field that uses tinymce, so this could be a good substitution. Drop the 'main.js' code for applying the wysihtml5 to the textarea and just use what c5 builds, then style that to match the old layout.