Great, [Dorotea]! And thanks also to [Rita Orlando]. So, Dorotea, the way to do this is to edit the task and assign it to yourself. Then get down to the redesign itself, and mark the task as done when you are finished. You are already a site administrator, so have the authorizations you need to make changes. This wiki contains useful information for using the Edgderyders backend to modify the website.
Ok, I have the beginning of an answer to my question 2 (the only one that’s technically hard). It would be tempting to just add a text field asking people where they come from, but it turns out the clean way to do this is to run mapping modules that geocode correctly that information. I found a recent comparison of mapping modules on the Drupal website. Earlier this year I did a seminar on geodata. The teacher advocated Leaflet (visualizes against OpenStreetMap instead of Google Maps, which is probably better for Edgeryders commitment to openness); apparently, installing the Leaflet module you get an option in Views to output the view as a map. Sweet!
I am asking around for a recommendation as to which modules to use.
Thanks for the hints, interested to see what people might recommend you finally.
Dorotea and me had also been looking for modules that could take and visualize a geolocation as a field value, and provide a vicinity search on that basis. Our preliminary result is that it would be possible with these, alternatively:
The best part of geofield is that people could optionally also input a polygon shape for a map location, such as to say “I am based in all of Western Europe” for example. For the nomadic folks …
We have been hacking the user profiles with Matthias
and we have added the following:
where are you based ( to indicate the area, city, several cities or places - it’s a text field )
where are you coming from to Lote3 ( to help with travel arrangemets ) (text field, people can write possible places or events they will be/attend before Lote3 )
As Matthias mentioned in the future we would like to add maps.
the field at the registration to identify spam registrations ( which I mentioned in another task concerning spam )
we are thinking and planning further improvements (adding maps and grouping fields, for example lote3 fields would be in some: I attended part, after the lote3 event)
task still in progress but most important fields for now are there (not required, but poeople can start fill it in if they wish)
Hi guys, and thanks for this! However, I am getting a bit confused, as [Matthias] always told me you need clean data in the back end in order to enable nice things on the front end. In this logic, the conceptually geographic information on “where are you” should not be stored as text data! Do you still agree with that? If you do, then the most logical path seems to me to be the following:
remove the extra text fields you created.
install the modules that add geodata handling capabilities to the platform (I spoke to my favorite Drupal guru in Italy and he recommended: Geofields for data storage, Views + Leaflet for visualization)
re-add the extra fields, this time as geofields
BTW, later in September we will be moving to registration phase 2, where people who already registered for #LOTE3 tell us if they really will come or not. This would be the chance to get at least the participants to fill those fields. So the time for installation is in the next week.
No time for geofields at the moment, as that takes me a full afternoon to do right. There’s more important things for me to fix first, means when migrating to geofields we will simply have to put in half an hour more or so to migrate textual input to approximate locations in geofields (using polygon input).
its hard to believe but even comments can have bugs… I just had to fix one in the comment display, in the comment that i made … in the web development world there is always lots of strange fixing and de-bugging to do
the thing is that these software development dynamics can take over almost completely the act of design.
a typical result is that there is no real design direction strategy - but rather the design is a result of what the programmers can (and choose to!) deliver.
I am not dismissing that strategy - it has some special qualities, but I do believe it can intrduce a limiting constraint on what such development efforts can produce … especially when it comes to user experience.
A masterful designer once taught me that software design is a kind of storytelling. Unless there is space for design (often missing in open source dynamics) then a story is never quite told … even though one seems to be there just around the corner. Instead there are many paragraphs. sentences, pages … even occasionally beautiful phrases … but never a good story.
There is a story to be told around the user-profile and it may ripple out into the entire EdgeRyders website. If it is told then the development efforts may be better focused in a coherent and clear direction.
I commented because I was following the development of this task and felt an opportunity to point this out (since I believe it is a recurring issue and I hope to be able to contribute to more than the user profile page). It is a challenge when it comes open-source and collaborative development.
I get you completely on the appreciation … that is a “curse” that comes with technology. Much complaining little appreciation … however consider this:
when you drive/ride in a car - do you appreciate the pistons of the engine responding to high energy explosions? or do you appreciate the comfrotable seats, air conditioning, sound system or sexy dashboard?
most people appreciate things that from an engineering standpoint are superficial. most engineers appreciate things that most people don’t see (and can’t appreciate even if they did - engines look mechanical, complicated and dirty).
design can have an effect both ways. it can provide the “regular people” with the things that they can appreciate (which the engineers can overlook). it can also present the engineers with challenges they would not have anticipated on their own (sometimes making something that “regular people” can appreciate takes more effort then engineers expect).
I also believe that lack of appreciation from “regular people” is an obvious response to lack of appreciation (of “the regular people”) by the engineers. I have witnessed good design as reminding engineers that there are “regular people” that use their products and that they, the engineers, need to care about these people and what they need. you may be surprised how much appreciation “regular people” can demonstrate for little even cosmetic things that make their life better.
Very insightful, [iamronen]. You are on to something. And yet… ER has (barely) enough of a doer culture to express appreciation for behind-the-scenes work, as here:
this is why, when we spoke, I asked your permission to not get into the details of the framework. This lets me be free and true to user experience without being limited by the framework or my understanding of it. This means we may create friction between what we want to achieve (design) and what can be implemented (with reasonable effort) with the framework … we’ll cross that bridge when we get to it.
re: Appreciation
I wonder if this is more about unLearning then it is about upSkilling. I learned this lesson when I set out to become “self sustainable” and realized what a huge misconception that is. I depend on others to create the tools in my workshop (from a simple screwdriver to a power saw), to cut down trees and saw them into lumber with which I can build things … there is so much that I took for granted … and I had to stop and appreciate!!! how much is available to me to build upon.
There may be some people at the core of the ER website that will experience appreciation of its technicalities. But ultimately as the community expands and its work and outreach grow … the success of the system that drives the website will be when people don’t even notice its there … but are able to produce great work with it
You can group fields in the profile form with the field_group module that you proposed.
It was indeed the best for the job – good find! You can use it from a little form at the bottom of Account settings: manage fields, to show field groups on the form to enter user profile data (and the registration form, I guess). As we don’t use Account settings: Manage display any more (see above), field groups are not available for the rendering. Instead, that job has to be done by CSS layout of the view output.
You can edit the rendering of the top (single-column) part of the profile with the User Profile Fields view.
I had to replace the Drupal default renderer since some nasty stuff got inserted into the rendering that could not get adapted or moved, like “Report User”. That’s why the profile page now even looks uglier than before: I left the design job to you This change also means that the order of fields in the rendered profile is no longer controlled by the Account settings: Manage display page. Instead, it’s done in the view linked above.
You can edit the panels and layout of a rendered user profile page by clicking "Customize this page" resp. "Change layout" at the bottom.
This will affect the pages of all user profiles, since we did not “panelize the node”. The “Customize this page” functionality is also available in the backend here (different interface, same functionality).
So … have fun with some hacking, I’d say I guess you can ask Alberto if you need help with the interface of Views, and in case you get stuck with anything else, you’re invited to another hacking session with me. If you get stuck, no issue. It’s quite complicated stuff and it took me some hours to figure it out up to this point (and I did not even test all the features of your new “toolkit”, so you’re kinda in unchartered territory now).
That all sounds great, and I confirm I know how to use views. So, to summarize: user profile fields view controls the big top box in the user profile page, detailing personal information about the user. “Customize this page” let’s you move around blocks generated by various views.
In principle, you could clone user profile field view and make it into different blocks. Then you could have “specialized” blocks: a block, say for social media accounts, another for geo information etc.
[Dorotea], there is a design choce to make right at the start…
[Alberto], exactly as you say. I created that first view called “User Profile Fields” as a starting point / demo, and sure, you can split it into more views if you like.