With Art Textbook

Setting Up With Art Textbook for Classroom Use

The first time I tried to get With Art Textbook running on a school server, I spent about three hours wrestling with a dependency conflict that turned out to be completely unnecessary. The package requires Node 16 or higher, but the official documentation still lists 14 as acceptable. If you're installing this for a district or university department, make sure you're on the right runtime version before you even start the download process. I found this out the hard way after pushing a failed deployment to production at 11pm on a Thursday night. The installation itself is straightforward once you've got the environment sorted. Clone the repository, run npm install from the root directory, and then execute the build script. The default configuration will point to a local SQLite database, which works fine for testing but isn't suitable if you're planning to run this for more than twenty or thirty concurrent users. I switched to PostgreSQL early in my own deployment because SQLite started locking up whenever multiple teachers tried to access the same textbook module simultaneously.

With Art Textbook Configuration Deep Dive

Most people overlook the environment variables file when they set up With Art Textbook, and that's where things go wrong. The .env file needs at least these entries configured properly: DATABASE_URL pointing to your actual database, JWT_SECRET for authentication token signing, and STATIC_PATH for where the uploaded textbook assets will live. I've seen admins leave JWT_SECRET as the default string, which means anyone who reads the source code can forge authentication tokens. This isn't theoretical either. I audited a school district's installation last year and found exactly that issue. They changed it within the hour. The textbook import feature deserves special attention because it has a quirk that catches everyone off guard. When you upload a PDF, the system runs OCR processing in the background by default. If your textbook contains scanned images of artwork rather than selectable text, this is essential. But here's the problem: the OCR queue can back up quickly. During my initial rollout at the community college, we uploaded about forty textbooks and the processing pipeline stalled at around twenty-eight files. The logs showed the Tesseract worker had hit a memory ceiling. The workaround was splitting large uploads into batches of ten and increasing the worker memory limit in the configuration file from the default 512 megabytes to 1024 megabytes. After that change, all forty processed within about twenty minutes. Authentication is another area where the default setup works differently than most people expect. With Art Textbook uses a custom role system rather than the standard LTI integration that many learning management systems support. This means if you want to connect it to Canvas or Blackboard, you need to build an integration layer or use the API directly. I wrote a middleware script for our LMS that translates SSO tokens into the application's native authentication format. The tradeoff is that you maintain control over the integration but you also take on the maintenance burden when the LMS updates its SSO protocols.

Backup strategy matters more than most administrators realize. The textbook content lives in the filesystem while metadata sits in the database, and if you only back up one side, you'll have orphaned records or missing assets. I recommend a script that runs daily that exports both the database dump and the asset directory to an offsite location. Our current process takes about twelve minutes and creates roughly four hundred megabytes of compressed backup data for about sixty textbooks. The mobile experience deserves a mention because it's genuinely uneven. The responsive layout works adequately on tablets but breaks on smaller phone screens when viewing detailed artwork at full resolution. Images get cropped awkwardly and the annotation tools become unusable. If your student population primarily accesses the platform through phones, you'll want to consider a companion view mode or accept that detailed work will happen on larger devices. I discovered this limitation about six months into our deployment when fifty students submitted annotations through mobile devices and the file corruption rate was noticeably higher due to interrupted uploads. There's also a rate limiting feature built into the API that most people don't know exists. By default, the system allows one hundred requests per minute per IP address. This seems generous until you're running batch imports or having a class of thirty students simultaneously access the same textbook with annotations enabled. I saw the rate limiter trigger during a midterm week when fifteen students opened the same Van Gogh module at the same time. The solution was adjusting the rate limit in the configuration file and enabling session-based rate tracking instead of IP-based tracking. IP-based tracking causes problems in environments where multiple students share a single network address, which is essentially every public computer lab and many home networks.

Performance optimization becomes relevant once you exceed about one hundred textbooks in the system. The search indexing process runs incrementally, and if you've been adding content regularly without maintenance, the index can fall behind. I scheduled a weekly reindexing job that runs during off-hours and found it reduced search response times from about two seconds down to under three hundred milliseconds. The database query analyzer showed the unoptimized queries were doing full table scans on the textbook metadata table. Adding an index on the subject and grade_level columns resolved this completely. The annotation system supports collaborative markup, which is useful for peer review workflows but introduces complexity around concurrency. Two students editing the same annotation point simultaneously will cause merge conflicts that the system doesn't handle gracefully. I recommend establishing clear guidelines for annotation usage and considering a lock mechanism if multiple students need to work on the same material. Some institutions I've consulted with have implemented a booking system where students reserve annotation slots for shared textbooks. It adds administrative overhead but eliminates the conflict problem entirely. If you're evaluating whether to deploy With Art Textbook, the honest assessment is that it works well for its intended purpose: structured art history and visual analysis coursework. The PDF handling and annotation features are solid. The limitations around LMS integration, mobile responsiveness, and concurrent collaboration are real constraints. For a single instructor or a department with about fifty to two hundred active users, this solution is viable. Beyond that scale, you'll need dedicated infrastructure and ongoing maintenance commitment. I've been running this in production for about eighteen months now, and the total downtime has been roughly four hours across all of that time, mostly related to server maintenance rather than application bugs.

The update cycle is approximately quarterly, and each update requires testing against your existing textbook library because changes to the PDF rendering engine can occasionally break older documents that rely on specific font handling. I keep a staging environment that mirrors production and run all updates there first. Last November's update introduced a breaking change in how transparency layers were rendered in certain PDFs, and we caught it in staging before any students encountered the issue.