Can I upload a spreadsheet to the fixometer?

I was thinking about the issue James mentioned with historical data “deciding which Fixometer categories items in the spreadsheet belong to” - and that was definitely one of the steps I had to do on a small scale: going from the brief description of every item in my spreadsheet like ‘radio’, ‘HP printer’, or ‘trousers’, I had to manually decide for each and every one what Fixometer category it should be in. Then I had to do the same again on my second and third spreadsheet, remaking many of the exact same decisions but also a few new ones on each new spreadseet.

That wasn’t a lot of work for me because I only had in total about 70 rows, but I had to make a decision on every single row even if I’d made the same decision earlier in the same sheet or on a previous event spreadseet.

My suggestion as a result is that if it is possible to upload with the actual (needed) fixometer data a little extra data - specifically the Item name that has been manually mapped to a Fixometer category - then if the next version of the spreadsheet template download gets enhanced with these mappings and they can be automatically used, i.e. by using vlookup of all previous mappings item->category. All of a sudden then for my fourth spreadsheet I will only have to make decisions on the items that hadn’t ever been mapped to a category before. Or I could decide to change ‘HP Printer’ to ‘Printer’ and that’s a mapping I did on the first spreadsheet.

Happily this reuse of previous mapping item->category will also work for different languages for the items - once the mapping has been made once from e.g. Ordinateur or Computadora de escritorio to Desktop Computer then it will simply become part of the mapping table generated into the template spreadsheet.

There’ll be some routine maintenance to do every now and then when someone chooses a different mapping e.g. for Ordinateur to Laptop Large - but I’d have thought that’s a small price to pay to make it a lot easier to upload data. Other maintenance might be needed whenever you add a new category perhaps you review the existing mappings to things near that category and revise some of them to use the new category - this could (or maybe make a policy decision not to…) also revise all the existing fixometer data.

So how about it, @neil can you make the upload also store a column headed Item and record the mapping of Item->Category to be generated into the spreadsheet template? And maybe that Item field could be optional on the normal data entry page - if you use it then the Category field is likely to be filled in for you rather than you having to search through the list.

There might be another place to use this technique of storing of extra data to help with mapping of older spreadsheets to the fixometer - in my case for the repair result I had different values from the Fixometer, e.g. Repair Completed->Fixed, Repair not finished->Repairable and Irrepairable->End of Life. If these mappings can be stored with the uploaded data and then exported in the template, once again transforming older data into the fixometer gets a lot easier because you only have to worry about the blank cells which indicate there isn’t a previous mapping.

I’d also like to ask for a couple of other features which I don’t think should be difficult to implement - but I’m open to easier-to-implement alternative suggestions to achieve the same effect.

  1. Please implement this so the upload finds the columns it needs using specific headings for the columns, and doesn’t mind about/ignores columns that it doesn’t need - so I don’t have to edit my spreadsheet to remove what strictly speaking is unnecessary data, just for the upload. These extra columns must not be stored, because they might be housekeeping or relatively confidential data like the client’s name or something like that.

  2. Please can you add an allowed value for category such as ”Ignored row” so I can map e.g. the trousers, and tool sharpening items to Ignored row and they are simple ignored - again this is so I don’t have to edit/delete what is strictly unnecessary data for the purpose of the upload. I don’t mind if you store the important fields from these rows as they don’t contribute to the fixometer, obvs - but storing the data even though it is initially ignored will mean that in a future where fixometer starts taking non-electrical information all that needs revising is the mapping of trousers->Ignored row to trousers->light clothing and you get the data straight away.


1 Like

Great thoughts re: mappings @Ian_Barnard. Also really interesting that if you look at the current draft of the Open Repair Data Standard (general info and gory details) then the two areas you’ve highlighted (product category and repair status) are two areas left open at present for figuring out a general mapping. I think you’d find the standard very interesting, would love to hear your thoughts!

We were thinking that the next iteration of this spreadsheet template could function as a way to highlight what data maps onto ORDS and how. Showing how it maps into the Fixometer categories could be a first start to that. Ideally all groups will be able to do as you’ve done, which is to define your own mapping from your data to other categorisations. Let’s explore further, I’m sure @Monique will have some thoughts on how it can be implemented.

Great, do these events already exist in the Fixometer @Ian_Barnard? Could you point me to them? During the first testing of this it helps if the event exists, so we have an ID to work against.

That’s fine, we will only import a specific set of columns. However during testing you’ll need to send the spreadsheets us directly, so you would need to redact any personal information that you don’t have permission to share.

Yes I think that would be fine. Although the question of how to revisit these to import them in future when we are able to, will need a bit of thought (to make sure we don’t reimport anything that has already been included).

1 Like

17th Nov
19th Jan
16th March

Let’s do Novemeber first?

define your own mapping

Is this you saying that you think the mapping I produce won’t be shared? I was hoping that by uploading/storing those extra fields to the fixometer DB and then providing them back in the template, we could all contribute to the mapping? After all Food Mixer need only be mapped to Small Kitchen Item once by one person for all future Food Mixers to then be automatically mapped to Small Kitchen Item. There will be some troublesome things like the different sizes of screen/TV and laptop - maybe those should be excluded from automatic mapping - but otherwise why not share the mapping?

Re: ORDS - thanks for the link, yes it is interesting - one technical thing I’d suggest putting into it is some more formal terminology to make explict the requirements for compliance, as many W3 and other standards do, because using more precise terminology definitely reduces the scope for disappointment when trying to interchange. For example, from the http protocol standard RFC2616 section 1.2:

  • The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 [34]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be “unconditionally compliant”; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be “conditionally compliant.”

Other things that probably should be pinned down are character (unicode) encoding for the CSV, such as UTF-8 or UTF-16. Also maybe there should be a ‘ORDS Member ID’ in the export so that the CSV includes which member organisation produced it? Surprised there are no free-text fields for description of problem and it’s (non-) resolution.

1 Like

Not at all! In fact ideally the mapping can be collaboratively produced. If there’s a lot of overlap / consensus then hopefully existing mappings can be reused. Just there’s the possibility that a group may have lots of past devices recorded and they’ve used say ‘Mixer’ rather than ‘Food Mixer’. Or there might not be consistency across the category at all if it’s free text. In which case ideally the group can help with the mapping and any edge cases.

Good suggestion on terminology for must and should, we could clarify that better, and encoding.

There is Group Identifier for identifying individual groups, but were you thinking at a higher level (e.g. Repair Cafe Foundation, Fixit Clinic, etc)?

Problem is in the standard at the moment - in the module on Repair related data.

1 Like

Not at all!

Good :slight_smile: if someone maps Food Mixer to Small Kitchen Item (SKI), that’s one mapping and there’s no problem with also having Mixer=>SKI, and Whisk->SKI and Blender, and Spup maker, … - it’s many-to-one, they’re all valid. If there is no repeated use of same term because it really is free text then the source team is going to have to do some work to tidy them up as there’s no silver bullet solution.

There is Group Identifier … were you thinking at a higher level

Yes - The Restart project, etc. User doesn’t need to enter this, it can simply be inserted into the CSV export, but it makes a permanent identification of the source of a CSV.

Problem is in the standard

Problem says “Option from open codelist” - which I read as not a free text description, depends what the purpose of the field is, I just think that the vast range of options is going to make doing a mapping infeasible, so you may as well have free text. ‘Solution’ isn’t in there, so there’s no way of differentiating a fix which required e.g. soldering some dry joints from one that involved tightening a screw or cleaning a battery contact.

I’ve shared a spreadsheet with you @Ian_Barnard for us to test through - probably makes sense for us to do the testing in a direct message thread, so send me a message when you have some questions about it :+1:

A quick update on this - thanks to great work from @Monique and @Ian_Barnard we’ve had a first successful import of spreadsheet data into the Crediton event from November last year :tada:

We’re building up a template spreadsheet that can be filled in with repair data and then imported.
Plenty to reflect on from the first pass, we’ll be trying a round 2 on another event to refine the process with lessons from the first event. After than it would be good to test with another set of data from another group :slight_smile:


I’ve just picked up on this thread, having acted as host for the first time yesterday (with 2 trainee, now fully competent co-hosts).

Having heard highly credible rumours of difficulties transcribing flip chart data into the fixoometer, I prepared fixer’s records for all fixers, and mostly they filled them in very well. As well as fixer’s name at the top, the columns were:

Category of device | Make/Model & Estimated age | Problem/solution | Fixed/Fixable/End of life | Fixable: Next steps or EoL: Barrier to repair

This worked well and was easy to transcribe into the fixometer though estimated age was rarely completed.

I quite like the idea of a spreadsheet but the flip chart is almost a Restart meme. There’s great value in having a long list on public display with a good smattering of smiley faces. What would be really good would be to enter the data in real time onto the fixometer displayed on a large screen, with the running total of kg of waste and CO2 displayed in a non-scrolling header. But I’m mot sure I’ve ever attended an event at a venue with the required technology.

The other thing that would have been very useful as I entered the data in the fixometer would have been a field for the fixer (not limited to members). Correlating the fixer’s records with the flip chart wasn’t easy even though we recorded fixer’s names on it. I could then have sorted fixes by fixer in order to double check. It would be especially useful when extra information or clarifications come in after the event.

Thanks for this Philip. Hope the event went well!

Glad to hear entering data into the Fixometer went well for the most part.

I definitely agree that there’s value in having a big, public list of ongoing and completed fixes. I’ve been to events where people wondering by or arriving have used the flipchart as a way to engage and understand what’s going on. I’ve even been to an event where they did project the Fixometer onto the wall, but this didn’t work that well: there wasn’t much available wall space and there was too much light to see it well.

As to recording individual repairers’ names, Janet recently mentioned why we don’t currently support this in a different discussion:

Hope that makes sense!

To summarise then, do you think you would use the spreadsheet in future once it’s ready?

Just noting @james @philip that one feature/work-around to liability and “assigning” repairs would be a “favourite” feature :star: that would allow fixers to keep a list of favourites, but this would not be tantamount to “claiming” a repair, it could be interpreted however the fixer chooses…?

(Also noting we need to do more to encourage fixers to review/contribute to fixing data after events, it’s currently not happening as much as we’d hoped…)

1 Like

I didn’t start off by using the whiteboard, and although I can see the attraction we need to have a form filled in & signed and that now helps to collect the data needed for the fixometer - maintaining a second whiteboard version would complicate things, I think. I’m wondering about having some of these scoreboards to make a visible display of the number of customers and fixes

I understand the liability issue. Would it be solved if that field were only visible to hosts and the fixer him/herself (if that were possible)? A favourites feature only works for the fixers themselves and doesn’t help the host in reconciling records afterwards.

@philip The reason I want spreadsheet upload is because I always capture my registration forms in a spreadsheet so I can report metrics to my funding source - not all that info should/needs to be uploaded, in fact there is other private info in my sheet for each event like the customer’s name and contact details, and whether they are happy to receive occasional emails. So maybe recording the repairer locally (and not uploading to Fixometer) would be enough?

1 Like

I’m looking forward to being able to upload the almost 1000 repairs we have from the Cambridge Area Repair Cafes - but I have also made the same offer to RepairMonitor - and we’re going to have to be careful that we don’t double-count our statistics!

We really want to avoid the worst-case scenario which is being forced to handover this kind of data.

See your point about fixers and hosts, but we hope that hosts start consistently inviting fixers to contribute to the data after the fact, and fixers get accustomed to going in and helping improve the data. There is probably more we can do to encourage this!

It would indeed be really good if we could get fixers to enter their own data (or at least supplement it with a further level of detail), but the truth is most of us find any sort of admin a chore and in the interest of completeness and accuracy of data I see no alternative but for the host to collect and enter the data, or at least the basic minimum. I was pleased with the way the fixer’s records worked that I gave out at St Albans and might take to filling in one myself at other events I attend for my own purposes. When I’m fixing I’m often so concetrated on the task at hand that I completely forget about the last one, and when I get home and my wife asks me what I did I often have difficulty remembering!