Author Archives: admin

What bonuses (and companies) are for

Posted on by
Reply

I believe most large organisations these days have a mission statement; and the ones I’ve seen usually include words about providing excellent products and customer service. However, my own experience in recent years seems to suggest that many large organisations are now just dedicated to growing their businesses and making more money – despite what they say in their mission statements. Products just seem to get smaller (for example shower gel in a different but smaller bottle) or worse (tins of baked beans with sausages that now taste completely different and not as nice), and customer service is mostly abysmal (for example, long phone wait times, and bots instead of people). Furthermore, Chief Executive bonuses often seem to be tied to how much money is made. I wonder if any organisations tie their CEO’s bonus schemes to all the elements of the organisation’s mission statement. Would it make a difference if all organisations did that as a matter of course?

Some Combination Consequences

Posted on by
Reply

A few days ago, I completed the Preservation Maintenance exercise for the PAW-PERS and SUPAUL-PERS collections. Actually, these two collections no longer exist separately – they were merged together into a new Mementos collection in last years Combining Collections journey. During the Preservation work, I encountered a few issues directly related to the increased scope of the Mementos collection, and to the way I combined all my collections. They are listed in the bullets below and subsequently described in more detail:

  • File pathnames exceed system limits
  • Varied ways of filling in fields
  • Preservation Maintenance is a bigger job
  • More Preservation Maintenance work is required
  • Backing up becomes more complicated

File pathnames exceed system limits:  MS Windows limits pathnames to 256 characters unless you make a change to the Registry. When I combined collections, I deliberately included the contents of a folder in the folder title to make navigation easier, for example, ‘Documents/PAWCOL/Family History (Archive, Mementos, Display Case Items, Photos, Recordings, Story Boards, Trophies)’. This resulted in very long path names when combined with file names with a lot of detail about their contents (for example, ‘MW-BKS-0001-02 – 4 smaller books – The Rubryat of Omar Kyam, The language of flowers, A preliminary course of First Aid, and a midget English dictionary’. The titles of files which exceeded the 256 limit still remained visible, but there were two undesirable impacts: the file wouldn’t open in my PDF app and seemed to cause the app to stop opening other PDF files as well. Secondly, the ‘Copy as path’ function which I was using to compare the file titles with the index entries, wouldn’t produce the correct file name, for example, the MW-BKS-0001-02 file shown above came out as  ‘”C:\Users\pwils\Documents\APAWCOL\FAMILY~1\Mementos\MEMENT~3\MW-BKS~2.JPG”. I decided not to go with the registry change to rectify this as I’m not sure how it would affect the PDF app, and, in any case, I’m not familiar with messing about with the Registry. My priority is to get the PDF app working again properly and permanently. Consequently, I have started to take out inessential information from the relevant file titles to have them come in under the 256 limit.

Varied ways of filling in fields: The Mementos collection has combined 5 different collections – all of  which had different ways of providing information in the ‘Physical Location’ field. Consequently, the Excel Filter drop-down list of different physical locations was very large and varied. So, I imposed a standard whereas all physical locations started with terms like Study, Chest, and Loft; and with a standard form of subsequent words. This is an obvious point, but when you combine several collections into a single index a degree of normalisation work is inevitably necessary.

Preservation Maintenance is a bigger job: when my two collections PAW-PERS and SUPAUL-PERS were separate collections with separate indexes, I had conducted Preservation Maintenance on them separately in previous years and had separate Preservation Maintenance Plans for 2025 for each of them. They contained about 800 and 750 items respectively. However, the new Mementos index/collection now not only contains their 1550 items but also about 550 items in the CONTRAB collection and another 220 items in the Computer Artefacts collection – a new total of about 2320 items. Furthermore, the physical items in each of these four main elements are all stored separately in different locations and in different ways. Inevitably this vastly increased number of diverse items has meant that the Preservation Maintenance exercise for the new Mementos collection took a great deal longer than the previous separate exercises, and was a good deal more complicated. This makes a difference because Preservation Maintenance seems like an overhead task, and the bigger and more complicated it is, the less motivated the owner may become to undertake it. It seems there may be trade-off between combining indexes to make them easier to manage and access, and making the Preservation Maintenance easy enough to be carried out regularly and reliably.

More Preservation Maintenance work is required: Before combining collections, I was only undertaking Preservation Maintenance work on four collections all of which have indexes – PAWDOC documents, Photos, and two separate sets of Mementos. Having combined all my collections, I now have some 40 collections which potentially need Preservation Planning work – many of which have no index. This is a potentially huge increase in work – though, at this point, I don’t really know what is required and whether it is best to deal with all these additional collections together or in smaller separate groups. One key criteria to be considered will be which Preservation arrangement has the greater chance of actually being enacted and not just simply put on one side as being too difficult or time-consuming. I will have to investigate the implications and will document my findings in a subsequent post.

Backing up becomes more complicated: As documented in earlier posts, in combining collections I have made considerable use of shortcuts. For example, within the ‘Entertainment Recordings (Movies, Music, Spoken Word)’ section there are shortcuts to the Windows Videos library, the  Windows Music Library, and to the Spoken Word folder within the Windows Music library. So, just copying the contents of the ‘Entertainment Recordings (Movies, Music, Spoken Word)’ folder will not provide an adequate backup. Care will need to be taken in specifying and carrying out backups to ensure that copies of the appropriate material are actually taken.

Proofs Submitted

Posted on by
Reply

The proofs for Collecting in the Icon Age arrived, as scheduled by Springer, on Friday 9th May in the form of a web site providing unformatted web pages for each chapter which could be edited to a certain degree. In addition, formatted versions of each chapter were provided in separate PDFs. We duly completed the editing after getting answers to some queries; and we submitted the revised chapters yesterday morning.

We were advised to provide comments adjacent to issues for which no editing functions were available, so we hope these will be sufficient to prompt the revisions we want. We also requested changes to the layout of some figures and tables, but they are subject to house style, so we are less confident that they will be enacted. However, we have done all we can – the proofing process is now closed. The only remaining influence we can have on the book is if Springer asks us questions or asks us for advice on specific points.

The Springer web site is currently advertising 6th July as the publication date – though this does seem quite fluid – a week or so ago it was 3rd July and then it went to 10th July for a day or so. However, the site has been consistent in advertising a softcover version and an ebook version – though no prices are provided. I also believe the book’s chapters will be available for purchase separately – but have seen no information about that. I have no idea if anything special happens on the day of publication, though I’m hoping we will be sent our copies of the book on the day or shortly afterwards. The next couple of months will be an interesting eye-opener for me of how contemporary publishers operate.

Some Photo Collection Assumptions

Posted on by
Reply

Addenda to ‘Organising Family Photos’

For the last ten years or so, I have been diligent in including the photos we receive from our family through social media and messaging, into our Photo collection. This endeavour has required me to request, a) more often than not, a higher res version than the one that has come via social media, and/or b) further information about the contents of the photo i.e. the people, places, or events that are being portrayed. Often, I would need to request the dates of the photos as well because that information seems to get lost when a photo is downloaded into the social media systems we use most – WhatsApp and FaceBook. Inevitably this has been a rather painful process – particularly when there were more than four or five photos involved. Responses were sometimes slow in coming, and replies sometimes hinted at an undercurrent of annoyance at the work that would have to be done.

My requesting of additional information had gone on since photos started coming through social media, and it was typically a tortuous process. It wasn’t that my offspring were unwilling to help, but it was time-consuming for them – and they didn’t fully buy-in to the idea that their photos needed to be an integral part of our photo collection. it reached a head just before Xmas last year when I was doing my regular yearly-or-so intake of new photos. At that point I concluded the buy-in was just not there, and that I was just imposing my own requirements on other people. I decided to be more selective about what I saved from social media and to be satisfied with the resolution delivered and the information that came with it. So, for example, if a photo of my grandchildren with someone else at an unspecified event arrived with a cursory description and sized at 125kb, I would include that version in the collection with a title which didn’t identify the specific event or unknown person, and with whatever date was provided in the social media message.

I recount these experiences because they relate to some general assumptions I had made when assembling the family photo collection as recounted in the ‘Organising Family Photos’ journey. To recap, the collection was assembled by gathering, indexing and scanning all the photos belonging to different elements of the family – my parents and their ancestors; my own before I met my wife; my wife before she met me together with her parent’s photos; and my wife and I’s photos after we married. Each of these four sets of physical photos were placed into sets of four differently coloured photo albums; and I reasoned that my offspring, and their offspring down the generations, would value these collections and would find them helpful in understanding where they came from and who they were.

In assembling these collections, I encountered photos that other people had sent, in addition to the photos the owners had taken themselves. These were often, but not always, photos of grandchildren and other branches of the family. I had assumed that collection owners would see such donated photos to be part of their photo collections, and consequently I had included them in the assembly, indexing, and scanning work. This was the background to my subsequent attempts to collect and catalogue photos provided to me and my wife through social media and messaging systems; and indeed, it has produced a subset of organised and indexed photos, all with information-rich and accurately-dated titles, which provide a rich historical record through a period of about thirty years when our offspring were leaving home, finding partners, and having children. I have no doubt they will enjoy looking at this record sometime in future years, but that is not the point. They will see it is a bonus, not a necessity fulfilled.

Another assumption I made when I was assembling the collection, was that if I provided a flexible structure for the indexing and albums, then other members of the family might maintain their own indexes and albums within the overall structure. However, not only has there been no interest in employing the flexible structure, family members do not seem to undertake any detailed cataloguing of their photos at all – so far as I know. One of the reasons for this is undoubtedly that a) these days people take and receive hugely greater numbers of photos than they ever did before, and therefore the workload in cataloguing is now very much greater than previously, and b) the facilities for retaining, organising, and searching for photos, both in mobile phones and in photo-sharing systems, are now very much better than ever before. In the face of these two changes, it is unsurprising that the workload-heavy approach I have been using to maintain our family photo collection, has not been taken up by family members, despite the fact that a template framework for the activity has been fully worked out and documented, and is easily accessible.

Having said all that, what of our Family Photo Collection, that I envisaged would be passed on down the family generations? Well, at present the physical collection consists of some 76 albums and is increasing by roughly one album every year (only a subset of each new crop of photos goes into the physical albums). This is now a HEFTY collection of physical volumes requiring a bookcase of its own. I haven’t asked any of my offspring how they feel about having to take it on when we die, but I suspect they might find it inconvenient, if not an imposition. Furthermore, the fact that a more comprehensive digital equivalent is available may make the eventual disposal of the physical volumes more likely. However, these too are simply my assumptions which, as we have already seen, have often proved to be incorrect.

The collection as it stands, provides a history of the family from the 1870s – some 150 years. In principle this would be of interest to family members of the future: it would enable them to get a sense of where they came from and to have a picture in their minds of what their ancestors were like. My assumption has always been that people instinctively want to know these things – though I do also believe, that, once people know the information is available, they have less interest in finding it out and examining it. This line of reasoning suggests that having a family photo collection going back 150 years will satisfy the instincts, but will not inspire any detailed inspection of its contents nor any particular regard for its worth; but, again, these are only my assumptions.

The fact that the complete collection is in digital form does provide a number of downstream opportunities that are not afforded by the physical album collection. In particular, a copy of the digital collection can be given to each offspring down the generations. It will take up relatively little digital space, will be easy to access, and will provide rich information in the file titles. As such, it ought to be a desirable asset, worth having and preserving and passing on. It may only contain the photos from a particular 150 year era; but it may inspire future owners to selectively add photos from subsequent times. However, future digital capabilities may bring more far-reaching opportunities. In particular, AI would seem to have all the capabilities to add additional material to the collection automatically. The cataloguing format – an Index Entry (Ref No, Description, and Date) and File Title (Ref No, Description, and Date) – is clear and simple and well within the capabilities of a Large Language Model (LLM) AI, let alone a future more all-singing, all-dancing version. There would, of course, be the danger of an LLM AI producing hallucinated index entries and titles, and even actual photos, so owners would ideally need to be checking what is produced, and that may not be done as diligently as it should. Nevertheless, it seems quite feasible that a collection could be grown in that way.

Unfortunately, the larger the collection grows, I can foresee that future generations will have less desire to fully explore its contents. However, that perhaps is immaterial: the contents will always be there to answer a query or to satisfy a general desire to explore the family’s past. It doesn’t have to be thoroughly explored to be useful. Interestingly, there are probably some comprehensive family photo collections that do already extend through the generations and which could be used to explore what the current downstream offspring think about them. The example that immediately comes to mind is the British Royal Family, and no doubt there are other Royal or Wealthy families which have similar extensive collections assembled and maintained by paid curators. The views of the offspring would be atypical because of their circumstances, but might, at least, throw a little light on the matter. Perhaps such research already exists – I haven’t investigated that question myself.

I have been able to muse about the future of our photo collection because it does actually exist as a whole family collection which can be easily passed on through the generations. This is not so true of photo collections that exist on people’s phones or in some cloud system. It is not clear what will happen to such collections in the decades to come. No doubt some will get passed on, and perhaps some AI in the future may organise and research them in some way; but they will, initially anyway, be less coherent and will represent only a narrow subset of the family. Having said that, there are now so many photos being produced and stored in the world that it is difficult to foresee what will happen to them all in the centuries to come.

This post has been all about the assumptions I have made – and continue to make – while organising and adding to our family photo collection. Here’s a summary of them – with some notes about their validity.

  1. My offspring, and their offspring down the generations, might value our family photo collection. Notes: the jury’s out on this. None of my offspring have expressed any more than passing interest in the overall collection.
  2. Collection owners consider donated photos to be part of their overall photo collections: Notes: I know my wife takes this view because she actively saves such photos; but I don’t really know whether my offspring do or not.
  3. Other members of the family might want to collect their photos within the framework of a family-wide indexing scheme. Notes: this notion was wildly wide of the mark. There has been no interest whatsoever.
  4. My offspring might feel it inconvenient, if not an imposition, to have to eventually take over the photo collection, especially as it grows in size. Notes: perhaps they may become more positive about it as they grow older – it seems to me that age does seem to spark interest in the past.
  5. The fact that a more comprehensive digital equivalent is available, may make the eventual disposal of the physical volumes more likely. Notes: Only time will tell.
  6. People instinctively want to know where they come from and to have a picture in their minds of what their ancestors were like. Notes: there’s probably been loads of research on this – but I haven’t investigated.
  7. Once people know that the information they want is available, they have less interest in finding it out and examining it. Notes: it would be interesting to see if there’s been any research on this.
  8. The family photo collection going back 150 years will satisfy the instincts of my offspring, but will not inspire them to make any detailed inspection of its contents, nor to increase their regard for its worth. The larger the collection becomes, the more likely this is to be the case: Notes: none of my offspring, as yet, have undertaken a detailed inspection of the collection.
  9. My offspring will think that the digital family photo collection which is easy to copy, easy to access, with information in the file titles, and taking up relatively little digital space, is a desirable asset to have and pass on down the generations. Notes: only time will tell – there has been no discussion in the family about this.
  10. Even if future generations have little desire to fully explore all the collection’s contents, they will still value having it available to answer a query or to satisfy an occasional desire to explore the family’s past. Notes: my offspring and their children do sometimes look at particular albums.
  11. Having a copy of the family photo collection – even if only in digital form – might inspire my offspring to selectively add photos to it in the future. Notes: only time will tell.
  12. AI will have the capability to add additional material to the collection automatically in the future. Notes: this may make it easier to curate the collection, but I, personally, would not have confidence in its reliability until it had been shown to work over an extended period.
  13. Photo collections that exist on people’s phones or in cloud systems are less likely to be passed on down the generations. Notes: only time will tell.
  14. As AI becomes more widely integrated into computer operating systems, it may take over the task of managing photos, and this may well increase the likelihood of photo collections being passed on down the generations. Notes: this is a double-edged sword – AI may help a collection get reliably passed down the generations – but will the objects in the collection, and the information about them, be genuine, valid, and true?

One final point: my acknowledgements must go to all the members of my family who are unknowingly providing the observations upon which I am basing my thoughts and opinions. I have only once explicitly sought their views (that was when I was assembling our photo collection back in 2015). Other than that, I may be misrepresenting them. If so, I apologise.

The Rationale for Addenda

Posted on by
Reply

This Journey contains afterthoughts on Journeys already completed. The musings have not been added to the original Journeys because those Journeys are completed and closed, and are not being reproduced in subsequent Journey hardcopy books. The Addenda Journey, however, will stay open as long as the pwofc.com website is open and I am still alive and able. Each Addenda post will be specifically related to another existing Journey in pwofc.com.

Proofs w/c 05May, Publication 02June

Posted on by
Reply

We received the schedule from Springer yesterday. It’s planned to send the book page proofs to us in the week commencing 5th May, and we have 12 days to review them and provide corrections. The Springer web site is now specifying a publication date of 2nd June. In the meantime, we’re working on some supplementary material that we plan to publish elsewhere in pwofc.com also on 2nd June – the analysis we undertook to identify the practice hierarchy, an overall practice hierarchy diagram, and an expanded overall set of references.

The Brave New MD World

Posted on by
Reply

I started looking for a replacement for my uGrokit app with a search for ‘simple database apps for the iphone’. The first hit that came back was iDatabase on the app store, and when I looked at that, the app store also suggested Collections Database, easyAsPieDB Database, Formbook, HanDBase Database Manager, and Memento Database. After doing a bit of netsurfing to find out as much as I could about them, I decided that Memento Database would be worth a try, so I downloaded it and imported the first 5 records, then the next 5 and then the next 20. At that point I decided this was probably going to work for me, and loaded up the other 120 or so records. This wasn’t a particularly scientific process, but I suspect its fairly typical of the way apps are selected from the huge number that are available. I had no desire to do detailed analyses for days and days: I just wanted something that works.

The key characteristics that made me decide to go with Memento Database (MD) were the ability to:

  • create and edit fields at will, and to easily reorder them using finger movements;
  • import data in csv format;
  • search across all fields very easily and quickly;
  • take photos from within the app;
  • export records in CSV format;
  • just have a local copy at no cost.

Interestingly, the one thing I’ve found really difficult about MD is trying to ascertain if I can really use it for free, or if at some moment my iPhone/mobile account is going to get charged. The problem is that the current ‘Free’ plan I’m on is limited to 100Mb storage, but it’s not clear if that 100Mb is for cloud storage or not. For now, I’m assuming it must be for cloud storage because the iPhone says that this app is taking up 4.67 Gb of which 4.63 Gb is being taken up by Documents and Data. I don’t understand this sizing as it works out at over 29Mb for each of the 155 records – very strange. Anyway, I shall continue to use the app locally and will keep my fingers crossed that it doesn’t lock me out at some point in the future. If that should happen, I’d have to decide whether to tie myself to the £35 a year charge, or whether to look for a replacement.

The process of getting the data from my uGrokit app into the MD app was particularly tortuous, and demonstrated how important it is to retain collection data in a transferable format. The uGrokit app would, on request, send a list of all the data in the body of an email as in the example shown below:

  • Description:                                   Numark TTUSB Turntable with USB interface
  • Type:                                             Item
  • Item Serial No:                              285
  • Container Serial No:                     Not a container
  • Position Serial No:                        Not a position
  • Item category:                               Hi-fi & video equipment
  • Item Owner:                                  Paul
  • Item or Container Condition:        Good
  • Container this Item or Container is contained in: No container
  • Position this Item or Container is placed in:         P4
  • Date this record was created:     12/10/2016
  • Container security status:           Closed
  • Date removed from loft:              (no Date removed from loft)
  • EPC:                                           (none)
  • image key:                                  2016_10_12_07_00_14_07668572.png

I had to put this material into a spreadsheet and save it in csv format in order to import it to the MD app. I made several different attempts to do so including using Excel’s ‘Get data’ function which I couldn’t understand; and copying and pasting chunks and deleting unwanted material. I ended up just copying and pasting the description and then manually filling in the necessary fields (the ones underlined in the example above). I did this on my laptop in tranches with a small number of records in a spreadsheet to start with and then, as I grew in confidence with the app and the process, I increased the number of records until all 155 had been dealt with. As I did each spreadsheet, I emailed it to myself, picked it up on my  iPhone, saved the file to the iPhone’s file system, and imported it from there into the MD app. As I did each import, I discovered foibles of the import process which I was able to address in subsequent csv spreadsheets. For example, apostrophes in the description text (such as “from Paul’s study”) resulted in the text following it being placed into a new record; so, once I figured that out, I eliminated apostrophes from subsequent spreadsheets.

As I compiled the spreadsheets, I was also able to eliminate items that had been removed from the loft: when I designed the uGrokit database I had included a ‘Date removed from loft’ field rather than opting to simply delete the item concerned, because I wanted to have certainty about what had been there and when it was removed. However, with this new app my priority was to keep the number of records down in case I should surpass a charging threshold, so I elected to eliminate items that were no longer in the loft. For the same reason, I did not include the records (including photos) for each of the 32 Positions in the loft (which had been included in the uGrokit database).

Once all the records in the last uGrokit email had been included, I then had to manually create entries in a final csv spreadsheet for the 24 new items that had been added after the last uGrokit email had been sent in January 2023.

Finally, all the spreadsheets were finished and the information imported into the MD app. However, the records from Ugrokit had come with only image file names and not the images themselves, so I then had to go into the loft and take a photo of each of the 155 items. Despite being a laborious exercise, it actually doubled as a useful stock check as well as enabling me to rectify errors in the Position information.

The loft database is now complete and fully operational as a Local ‘Library’ in the MD app. So far, I haven’t been charged anything or been asked to upgrade. The app seems to do everything I need it to – though, of course, time will tell. It has just three flaws that I can see at the moment:

  • As already mentioned, the records in the app are taking up a huge amount of storage (some 29Mb each) which I don’t think can be attributed to the photos. I don’t understand this and fear it might have unpredictable implications.
  • When entering the Loft ‘Library’ the records are displayed underneath a search bar and a field title bar. However, when you scroll down the records, they scroll up over the field title bar and the search bar and off the top of the screen. It’s not a critical problem – but its not what I would expect.
  • Scrolling through the records quickly can be a little hesitant as though the processor is having to work excessively. This is even more pronounced when the photo field of the records is displayed (there is only room for the first 6 fields to be displayed when the iphone is held landscape, so the photos only get displayed if you scroll to the right and then scroll up and down). In fact, not all the photos appear as the records are scrolled through – some of them just have time circles until they appear. Perhaps this issue is simply because I’ve got a relatively old iPhone. However, it doesn’t really concern me because I would rarely scroll through all the records. My useage is almost entirely based around searching for a particular item.

These issues – particularly the first one – are a little disconcerting; but having gone to all the effort to populate my loft database in the MD app, I’m not inclined to do further investigations right now and to potentially have to go through it all again with another app. Instead, I’ll wait and see how things go – and in the meantime export a copy of the MD Loft database, as well as saving a copy of every photo to my iPhone photo library: I’ve learnt my lesson about retaining data in a transferable format. I have retained my old uGrokit loft database on my iPhone: there seems no particular reason to delete it until I have to. However, all additions and changes will be made in the MD app going forward. I’ll report back on how things work out with the new app in a year so.

EOL and RFID

Posted on by
Reply

It’s been over 8 years since I wrote the last entry for this particular journey and started using the uGrokit iPhone app. Since then, the app has worked reliably for me across at least two different iphones and provided easy to access information about the 180 or so objects in our loft. However, a year or so ago, the facility to have a backup email sent listing the contents of the database, stopped; and soon afterwards my local version stopped synching with the remote cloud copy. Investigations revealed that the uGrokit company had been acquired by Turck (a German international supplier of factory and process automation technology) in April 2017, and that the uGrokit app was now EOL (End of Life). I had truly taken my eye off the ball. Turck continues to sell the U Grok smartphone readers but, instead of a ready built app, it provides a software development kit for users to build their own databases.

This is a classic digital preservation problem for collectors using technology to support their activities: you have to keep abreast of the technology or risk losing access to your digital content. It’s demanding enough to have to do this in a commercial enterprise; but for a private individual it is an unwanted responsibility easily brushed under the carpet.

Anyway, I realised that I needed to get on and do something because, although the uGrokit app continued to work OK on my iphone, there is no guarantee that it will stay that way, or that it will work when I upgrade my iPhone; and there is no longer any support operation that I can call on for help. Furthermore, any new entries I make in the app will be locked in the app and not downloadable to another format which can be reused in another system.  For all these reasons I decided it was time to find another iPhone app.

A key starting point was the question about RFID. As can be seen from my previous post in 2016, it had been my intention to try to acquire a uGrokit Reader and to try fitting RFID tags to all my loft objects. Well, I did try to do that but nothing came of it. I couldn’t acquire a reader on loan or second hand, and I couldn’t really justify the full price spend of £395 + VAT. Meanwhile, my uGrokit app was working very nicely. I lost momentum and abandoned the idea. Now, however, I needed to be clear if RFID was going to be on the requirements list for the new system I was going to look for. Interestingly, the answer was quite clear: No!

Over the last 8 years I have come to realise that adding an RFID capability would not improve my loft system for the following reason: the position of each loft item is specified in the database; and each position is about three feet wide and 5 feet deep. Most objects are either fairly large in their own right, or else in a container like a case which is also fairly large: so, it is relatively easy to find an object when you know its position. When I want to find an object, I find its position by looking at the app, and then go into the loft armed with that knowledge. Having an RFID reader to point at the object once I get to the Position wouldn’t really make it any easier.

On top of this fundamental fact that I don’t actually need RFID to control my loft objects, there would be a whole lot of extra work to do to implement an RFID system. RFID tags would have to be bought and attached to each object. The tags can be either active with a power source such as a battery, or passive which reflect energy from the reader. I wouldn’t want to have to supply and keep replacing batteries so I would be using passive tags – UHF (high Frequency) passive tags (which can operate up to about 20 feet) as opposed to HF (Low Frequency) passive tags which only operate up to about 3 feet. The tags come in all shapes, sizes, prices, data storage capacities and ways of attaching them to their objects; so, I would have to undertake a selection exercise or be tied to the tags provided by the card reader supplier. The tags would also have to be programmed to identify the objects they are attached to. Special tags may be required for metal objects; and apparently metal objects (such as the TV arial in my loft) can affect the RFID signal.

Given all these complexities, I’m glad I don’t need to go down the RFID route. My tags are white Strung Tie-On Tags which cost about £3 for 100, and I already know how to tie the knot when I attach them to an object. I programme them by writing the Item Serial No on both sides of the tags with a black felt tip pen.

Back to the list of requirements for my replacement Loft app. These are the things that immediately spring to mind:

  • It must operate on an iPhone.
  • It must enable me to specify the fields I require
  • It must enable me to take photos of objects from within the app
  • It should be free or very cheap to use
  • It should enable the export of the data to a csv file (for backup or transfer to another system)

With these points in mind, I set about looking for a suitable app. The following post documents how I got on.

Publication Date – 16th May 2025

Posted on by
Reply

Springer are now advertising that our book – Collecting in the Icon Age – will be published on 16th May 2025. A write up of the book, its contents, authors, and the formats it will appear in, is on the Springer website. Various booksellers such as Waterstones are also advertising the book and enabling customers to pre-order it. The price of the hardback version is rather high….

We have had no communications from Springer about the detailed contents of the book as yet, but have been advised that we will be sent a schedule which will include the expected date the proofs will be sent to us.