Content uploaded by Boban Dedovic
Author content
All content in this area was uploaded by Boban Dedovic on May 23, 2023
Content may be subject to copyright.
EHAMMURABI.COM CASE STUDY i
Preprint V.2.3.5
eHammurabi.com: A case study on developing user-friendly digital tools for complex
ancient languages like Akkadian
Boban Dedović
Division of the Humanities, University of Chicago
May 23, 2023
Author Note
This article is a preprint currently undergoing editorial and peer review. It is thus subject
to change. All errors and omissions are my own.
Boban Dedović (Orcid: https://orcid.org/0000-0003-4528-7239; Academia.edu:
https://chicago.academia.edu/BobanDedovic) is now at the OMNIKA Foundation.
Many thanks are owed to Martha T. Roth from the University of Chicago for
enlightening me about the importance and nuances of studying legal codes from antiquity. I also
wish to thank Professors Susanne Paulus and Herve Reculeau from the University of Chicago for
giving me a world-class education in cuneiform and the Akkadian language. Finally, a debt of
gratitude is owed to Peter Z. Revesz from the University of Nebraska, Lincoln, for demonstrating
the benefits of applying computer science to the study of ancient languages.
Partial funding for the publication of this article was provided by the OMNIKA
Foundation, a Nevada-based 501(c)(3) nonprofit entity whose mission is to organize and make
freely available all the world’s mythological contents. Website: https://omnika.conscious.ai
Correspondence concerning this article should be addressed to Boban Dedović. Email:
boban@uchicago.edu
EHAMMURABI.COM CASE STUDY ii
Preprint V.2.3.5
Preface
My initial object in creating a digital tool to study the Law Code of Hammurabi was to
accelerate my own pace of learning the Akkadian language. Whilst attending graduate school at
the University of Chicago, I was enrolled in a Mesopotamian Law class taught by the most-
learned Martha T. Roth. Simultaneously, I was entering intermediate-level study of the Akkadian
language. Between both classes, it came to pass that I was either analyzing or translating statutes
from the Law Code of Hammurabi up to six times per week. As a life-long practitioner of
computer science, I lamented having to open ten or more separate PDF files in order to fulfill my
obligations as a student of the Akkadian language. Accordingly, I began work on what is now the
eHammurabi.com digital tool. Within a few months after launch, the website surpassed 50,000
requests and began receiving incoming traffic from the likes of Wikipedia and other high-traffic
websites. A variety of individuals also contacted me privately to inform me that the
eHammurabi.com website alleviated the same frustrations I noted above. It therefore seemed to
me both fruitful and necessary to share the development journey I underwent, as well as some of
the important lessons that I learned about digital humanities.
I should do well to apologize to the reader for writing the present article in such a dry,
mechanical fashion. However, the digital humanities journal I intend to publish in demands
language suitable for a general audience. This requirement is unusually difficult to negotiate
because of the proprietary jargon commonplace to both the study of Akkadian and computer
science. Consequently, I resolved upon using plain English language in the body of the article
whilst reserving technical commentary for the footnotes. Finally, many complex topics were
intentionally oversimplified in order to promote participation from future investigators. It is
hoped that more practitioners of both disciplines will consider joining forces instead of admiring
one another from afar.
–B. Dedović, University of Chicago, June 2021
EHAMMURABI.COM CASE STUDY iii
Preprint V.2.3.5
Abstract
"If a man has destroyed the eye[sight] of another man, they shall destroy his eye[sight]," so reads
provision §196 of the Law Code of Hammurabi, dated c. 1750 BCE, one of the oldest and most
important legal texts in recorded human history. Many probably recognize this provision as the
principle of "an eye for an eye." However, the original source materials from which it is derived
from are less known. To unpack the inscription's linguistic contents, one must negotiate the
complexities of the Akkadian language alongside other challenges unique to the study of ancient
languages in general. Existing digital humanities projects have assisted researchers via the
distribution of relevant scholarly materials. Notwithstanding, there is no authoritative, widely-
available resource that consolidates multiple publications into a single resource. The
eHammurabi.com project sought to remedy this state of affairs by means of building a simple-to-
use digital tool. The present case study outlines how this new tool was built by describing its
development from start to finish. A systematic review of existing digital tools was conducted
before development began. Three arguments were posited: (1) digital tools like
eHammurabi.com must be both an aggregator and redactor of data from authoritative
publications; (2) the user interface is most important; and (3) the user interface must be designed
in accordance with a singular, pre-determined user goal that can be measured objectively. The
goal of eHammurabi.com was to enable users to find relevant linguistic contents for a given
statute as quickly as possible. Certain features of the user interface seemed to satisfy this goal: a
single-page website for all 282 statutes; a vertical multi-panel display that contains all required
contents for each statute; and a persistent left-side navigation menu. Following the website's
launch, a user study was conducted. Our data suggest that eHammurabi.com enables users to find
a statute's contents roughly ten times faster in comparison to print books and PDF files. These
results support our arguments. Website traffic data suggest that external reception has been
positive. Further research is likely required. Implications for practitioners of digital humanities
are discussed. Interdisciplinary cooperation amongst language experts and computer scientists is
recommended.
Keywords: Hammurabi's Law Code, Akkadian, cuneiform, computer science, digital
humanities
EHAMMURABI.COM CASE STUDY iv
Preprint V.2.3.5
EHAMMURABI.COM CASE STUDY v
Preprint V.2.3.5
List of Important Terms
Term
Domain
Meaning
Akkadian
Assyriology
A Semitic language belonging to the Afro
-Asiatic family of
languages that was
spoken in ancient Mesopotamia from c.
2800
–400 BCE
Cuneiform
Assyriology
One of the world's oldest
writing systems that was used by
various ancient languages
from c. 3400 BCE – 200 CE
Law Code of
Hammurabi
Assyriology
An important legal text from c. 1750 BCE
that contains
between 275
–300 recognized provisions
Transliteration
Linguistics
The process of converting the sound values from one writing
system into another
Normalization
Linguistics
The process of converting the meanings of words from one
language in
to another
User experience
Computer Science
A user's assessment of a device
, software application, or
website
as a result of interacting with it
User interface
Computer Science
The manner or means by which a user interacts with a software
application, website, or device that requires human input
User goal
Computer science
A specific task or desired outcome for users of a given device,
software application, or website
EHAMMURABI.COM CASE STUDY vi
Preprint V.2.3.5
Contents
1. Introduction and Approach ......................................................................................................... 3
1.1. The Challenges of Translating Akkadian Texts ............................................................. 3
1.1.1. Multi-Step Translation Process .......................................................................... 4
1.1.2. Access to Several Technical Publications ......................................................... 8
1.1.3. Knowledge of Proprietary Information ............................................................. 9
1.2. Common Practices Amongst Existing Solutions ......................................................... 10
1.2.1. Data Aggregation and Granularity ................................................................... 11
1.2.2. Interactive Multi-Panel User Interfaces ........................................................... 12
1.2.3. Note About Print-Format Predecessors ........................................................... 13
1.3. Priorities of eHammurabi.com ..................................................................................... 16
1.3.1. Task-Focused User Interface Design ............................................................... 16
1.3.2. The Importance of Design in Software ............................................................ 18
1.3.3. Defining an "Excellent" User Interface ........................................................... 21
2. Development and Execution ..................................................................................................... 22
2.1. Prototypes of Electronic Hammurabi .......................................................................... 22
2.1.1. Layout and Single-Page User Interface ........................................................... 23
2.1.2. Persistent Left-Side Navigation Menu ............................................................. 24
2.1.3. Multi-Panel Main Body Display ...................................................................... 25
2.2. Data Sources and Data Structure .................................................................................. 27
2.2.1. Determination of Authoritative Sources .......................................................... 28
2.2.2. Multi-Source Data Aggregation ...................................................................... 29
2.2.3. Data Scope, Architecture, and Granularity ...................................................... 30
2.3. Developing eHammurabi.com ..................................................................................... 32
2.3.1. The Benefits of Responsive Website Applications ......................................... 33
2.3.2. Data Storage Method and Core Technologies ................................................. 34
2.3.3. Designing a User Interface for Multi-Device Consumption ............................ 36
3. Results and Discussion ............................................................................................................. 37
3.1. Satisfactory Results ...................................................................................................... 37
3.1.1. Internal Results ................................................................................................ 38
3.1.2. Explanation of Internal Results ....................................................................... 40
3.1.3. External Reception ........................................................................................... 41
3.2. Implications and Future Work ...................................................................................... 41
3.2.1. Recommendations Applicable to Others ......................................................... 42
3.2.2. Future Work on eHammurabi.com .................................................................. 42
3.3. Summary of Case Study ............................................................................................... 43
References ..................................................................................................................................... 46
EHAMMURABI.COM CASE STUDY vii
Preprint V.2.3.5
List of Figures
Figure 1. Basalt Stele Artifact Containing the Law Code of Hammurabi ...................................... 2
Figure 2. Multi-Panel User Interface Utilized by the Perseus Scaife Digital Tool ...................... 13
Figure 3. Print-Book Arrangement of Contents in Ecce Romani III ............................................ 14
Figure 4. Print-Book Arrangement of Contents in Middle Egyptian Literature ........................... 15
Figure 5. Screenshots of Terminal vs. Graphical User Interfaces: MS-DOS vs. Windows ......... 20
Figure 6. Screenshot of an Early Prototype of eHammurabi.com Created in Google Sheets ...... 23
Figure 7. Mockup of Vertical Multi-Panel User Interface for eHammurabi.com ........................ 26
Figure 8. XML Data Structure for eHammurabi.com's Dataset ................................................... 35
List of Tables
Table 1. Three-Step Translation Process for §196 in the Law Code of Hammurabi ...................... 7
Table 2. Data Aggregation Content Summary for eHammurabi.com .......................................... 30
Table 3. Four-Level Information Architecture Tree for eHammurabi.com's Dataset .................. 31
Table 4. Results of Time-Tracking Study for Findings Statutes on eHammurabi.com ................ 39
EHAMMURABI.COM CASE STUDY 1
Preprint V.2.3.5
eHammurabi.com: A case study on developing user-friendly digital tools for complex
ancient languages like Akkadian
The object of this writing is to present the case study of Electronic Hammurabi–a digital
humanities project kindly provided at the following website address: https://ehammurabi.com
(Dedović, 2021). This website provides a comprehensive digital tool for studying the linguistic
contents of the Law Code of Hammurabi.1 The Law Code of Hammurabi is an important
collection of legal codes inscribed on a large artifact called a stele (see Figure 1). At present, it is
housed at the Louvre Museum (2023) in Paris, France. Scholars believe the artifact was created
c. 1750 BCE (Roth & Michalowski, 1995, p. 71). This date corresponds to the reign of
Hammurabi, the sixth king of Babylonia. Babylonia was an ancient empire located in modern-
day Iraq. The inscription is written in Sumero-Akkadian cuneiform, which is one of the world's
oldest writing systems.2 The language is Akkadian, which is a Semitic language that belongs to
the Afro-Asiatic language family (Huehnergard, 2011, pp. xxiii–xxviii). The Law Code of
Hammurabi contains a prologue, some 282 recognized statutes,3 and an epilogue. It is considered
to be one of the most important legal texts in recorded human history (Richardson, 2004, p. 11).4
The Internet has enabled the distribution of scholarly materials related to the Law Code of
Hammurabi. Some of these are print publications freely available to the public as Portable
Document Format (PDF) files. Various websites also provide English translations as well as
other language-related contents. Before the launch of eHammurabi.com, however, there was no
single, comprehensive, easy-to-use digital resource suitable for advanced study.
1 Here, the phrase "linguistic contents" is a simplified expression to denote contents that belong to several fields of
study: linguistics, orthography, epigraphy, grammar, and lexicography.
2 Writing systems and languages are not the same thing. Language refers to words and grammar whilst writing
system refers to the method by which language is inscribed unto a physical surface. Several other ancient languages
utilized a cuneiform-based writing system, such as Sumerian, Hittite, and Old Persian. The word "cuneiform" refers
to the practice of using a stylus in order to imprint wedge-shaped marks unto a solid surface.
3 The exact and total number of statutes is a debated topic for several reasons that cannot be treated here due to
space considerations. Both Abulhab (2017) and Richardson (2004) list 282 statutes in their most recent, respective
works, while Roth & Michalowski (1995, p. 71) recognize a range between 275–300.
The term "statute" is used in the present case study for the benefit of a general audience; however, it is probably
misleading because it implies that the statutes are comparable to that of modern legal systems. The same is said of
the term "law." In following the authoritative opinion of Roth & Michalowski (1995), we should thus do well to
regard the contents of the Law Code of Hammurabi as a collection of provisions that make up a comprehensive legal
text.
4 For a thorough treatment of this matter, see esp. Roth & Michalowski (1995, pp. 71–76).
EHAMMURABI.COM CASE STUDY 2
Preprint V.2.3.5
Figure 1
Basalt Stele Artifact Containing the 'Law Code of Hammurabi'
Note. Image compilation by Boban Dedović. Redacted from Louvre Museum (2023). The artifact is made from a
material known as basalt, and is roughly seven feet, four inches tall. Most of its surface contains the inscription,
which is about 4,100 lines long. The top of the left-side image that depicts two humanoid figures is called the
"fingertip." Many believe that the figure standing on the left is Hammurabi himself and the seated figure is Shamash
(Šamaš), an important Babylonian deity related to the sun.
Certain portions of the artifact are heavily damaged. Some scholars believe that these damages are the result of
intentional mutilation on behalf of individuals that disliked Hammurabi or the manner in which he ruled the
Babylonian empire. Such acts were not uncommon all throughout antiquity.
EHAMMURABI.COM CASE STUDY 3
Preprint V.2.3.5
That is, students, teachers, and researchers of the Akkadian language were forced to rely on
several technical, obscure publications. Such reliance was–and still is–necessary for serious
investigators. The nature of the Akkadian language and its study seems to be the cause of said
burdens. As shown later, this ancient language is not easy to negotiate because of its complexity.
Consequently, digital humanities projects focused on the Law Code of Hammurabi have special
needs. The following sections outline what these language-specific needs are, how the
eHammurabi.com project negotiated them, and our derived findings.
To understand why building a digital resource for the Law Code of Hammurabi is
uniquely challenging, it is first necessary to provide specific reasons; followed by a review of
how other digital tools have addressed similar challenges. These contents will substantiate why
the eHammurabi.com project adopted a unique plan via its treatment of priorities. To this end the
Introduction and Approach is directed. Three arguments are posited: (1) a robust digital tool
must be both an aggregator and redactor of several authoritative publications; (2) the user
interface of said tool is its most important aspect; and (3) the user interface must be designed in
accordance with a singular, pre-determined user goal that can be quantified and measured
objectively. The declared user goal for eHammurabi.com is summarized as follows: to enable
users to find a statute as quickly as possible. Next, the Development and Execution section
details how eHammurabi.com was crafted around this intention–from prototype to completion.
Finally, the Results and Discussion section reports the satisfactory results, their implications, and
summarizes the key takeaways of the entire case study. In sum, we attempt to demonstrate
hereinafter that eHammurabi.com's aggregation of data in a single-page, multi-panel user
interface allows users to find a single statute orders of magnitude faster than prior methods. In
our experience, digital tools that treat complex ancient languages like Akkadian may benefit
from extra emphases unto curating data from important sources, defining a clear user goal, and
using said goal in order to implement an appropriate user interface.
1. Introduction and Approach
1.1. The Challenges of Translating Akkadian Texts
Let us suppose that an English-speaking entry-level student of Akkadian or another
concerned party is interested in unpacking the linguistic contents of a single statute in the Law
EHAMMURABI.COM CASE STUDY 4
Preprint V.2.3.5
Code of Hammurabi. §196 has been selected as an example because of its general notoriety.5
The task seems to be complex because of three general challenges. Ancient languages like
Akkadian are complex to negotiate because they require a multi-step translation process, several
technical publications, and proprietary knowledge.
1.1.1. Multi-Step Translation Process
The process of translating Akkadian into English requires three challenging steps. The
first step requires converting the sound values of cuneiform signs into the English language. As
noted, the writing system used in the Law Code of Hammurabi is Sumero-Akkadian cuneiform.
Unlike the English alphabet,6 cuneiform signs represent either sound values or entire words. The
signs must thus be converted from cuneiform to the English language's writing system. This is
known as transliteration (Huehnergard, 2011, p. xxxi). For example, the two signs represented by
are šum and ma (Borger, 2004, p. 89; pp. 148–149). Because the signs represent
sounds, they are called phonetic. Many individual signs can have more than one sound value. In
an extreme case, one sign may have more than twenty possible values. Other signs represent
entire words. In this case, we call them logograms. For example, the sign has many possible
meanings (Borger, 2004, pp. 49–50). It may be a Sumerian logogram for the Akkadian word
šamû, meaning "sky" or "heaven"; a Sumerian word which is used before personal names to
indicate divine status; the Akkadian word ilum, meaning "deity"; or the sound value an, among
others. The translator must choose appropriate sound values for all of the symbols in a given
Akkadian text. For §196, there are a total of twenty-three individual signs, and many of these
have two or more possible meanings (Bergmann, 1953, p. 26).
The second step requires choosing the correct sound values for each sign. This is done by
determining the correct values and establishing word boundaries. In English, we separate words
with spaces. When we read the phrase "my eyes," we know that the space between "my" and
"eyes" indicates that there are two words. The use of spaces in English thus establishes
boundaries between individual words. In Akkadian, determining word boundaries is not as
simple. It is not uncommon for adjacent signs to have several plausible combinations. In the
5 Hereinafter, the § symbol shall stand for the word "statute" and the number following it shall correspond to one of
the 282 statutes in the Law Code of Hammurabi.
6 Modern English utilizes the Latin script; and each letter of the alphabet is an individual sound value.
EHAMMURABI.COM CASE STUDY 5
Preprint V.2.3.5
example noted above, we determined that represent the signs šum-ma. When combined,
they produce a single word, šumma, which means "if" in English (Roth et al., 1992b, p. 275).
This whole process of determining the correct sign values and establishing word boundaries is
called normalization (Huehnergard, 2011, p. xxxi). That is, the possible sound values from step
one must be converted into a coherent, "normal" Akkadian sentence. This step can be time
consuming. For example, longer sentences with more signs have more possible combinations.
Consequently, one must determine the boundaries for not just individual words, but also for
clauses or entire sentences.7 The translator must make lots of choices like these. Knowledge of
grammatical rules is thus also necessary. When dealing with verbs, different normalizations can
produce wildly different English translations, as is shown next.
The third and final step requires applying the rules of Akkadian grammar unto the
normalized sentence in order to produce an English translation. This may be particularly tricky
for native English speakers because Akkadian comes from a different language family
(Huehnergard, 2011, pp. xxiii–xxiv).8 Language families are like family trees–each tree has
branches of languages all derived from a single ancestor. But, here is the rub: languages
belonging to different families may have vastly different features. For example, normal English
sentences utilize the following word order: subject–verb–object. In the sentence "he walks the
dog," "he" is the subject doing the action, "to walk" is the verb of action, and "the dog" is the
recipient of said action. However, word order in Akkadian is usually subject–object–verb.9 In
English, this would be *"he the dog walks."10 Word order is but a simple difference. To be sure,
there are many more differences with Akkadian that are more difficult for native English-
speakers to comprehend.
A prominent difference between English and Akkadian is the manner in which words are
manipulated in order to produce certain meanings. The English language allows for the creation
of different related words based on what is known as a head word. For example, if we take the
head word "walk," we can create a number of other words: "have/had walked," "walked,"
7 Most ancient texts did not utilize modern writing conventions such as titles, spaces, or punctuation.
8 English is derived from the Proto-Indo-European family of languages, as is German, Latin, Greek, and Russian.
9 A notable exception to customary Akkadian word order is literary texts, wherein the verb is oftentimes first.
10 The asterisk * symbol indicates that the word or sentence is a hypothetical, impossible, or non-standard form.
EHAMMURABI.COM CASE STUDY 6
Preprint V.2.3.5
"walking," "will walk," "will have/had walked," the "walk," and "the walker." In each form, the
word "walk" is modified by means of adding a word before it or changing its ending. In
Akkadian, a completely different system for building words is utilized. In ultra-simple terms,
many Akkadian words utilize three consonants as a base. Then, a combination of vowels,
prefixes, or suffixes can build other derived words (Huehnergard, 2011, pp. 15–17). For instance,
if we begin with the consonants š–r–q, we may add some vowels between them to produce
šaraqum, which means "to steal" (Roth et al., 1992a, p. 53); by adding 'a–' as a prefix and the 'i'
vowel, we produce ašriq, which means "I stole." Other modifications to the three consonants can
produce nouns like šarrāqum, which literally means "he who steals" but is oftentimes translated
as "thief; robber." This method of building words is different from the English language, and
thus requires learning an entirely new paradigm. Such extreme differences extend into many
other facets of the language that space does not allow us to treat here.
Taken to completion, translating a normalized Akkadian sentence requires looking up
unfamiliar words in a dictionary and possibly comparing different translations. There can be
much variation according to the individual translator's style, as noted. For §196, the entire three-
step process is organized in Table 1. As shown, this statute refers to the well-known principle of
"an eye for an eye."11 Let it be known that the second and third steps rely on the determination of
the preceding ones. Consequently, a mistake in step one–transliteration–has implications for the
next two. It is not uncommon for practitioners of Akkadian to spend half an hour or more on a
translation of such length. Because of this, the following statement deserves especial notice:
probably no practitioner of Akkadian can quickly "read" a novel text on-sight. In other words,
while the laborious process noted above may become easier with experience, it is highly unlikely
that any expert would be able to recite an English translation as quickly as they would read the
English language.
11 Scholars of Mesopotamian law oftentimes refer to these kinds of punishments as lex talionis, which is a Latin
phrase that literally means "law of retaliation." This maxim denotes punishments that resemble offenses.
EHAMMURABI.COM CASE STUDY 7
Preprint V.2.3.5
Table 1
Three-Step Translation Process for §196 in the 'Law Code of Hammurabi'
Step
name
D
escription
Value
Initial inscription
0
. Cuneiform signs
Each of the five lines
must be
read from
top-to-bottom and
left
-to-right
Akkadian to English translation
1. Transliteration
Conversion of sign values into
sounds and words
šum
-ma a-wi-lum i-in DUMU a-wi-lim úḫ-tap-pí-id i-in-
šu ú
-ḫa-ap-pa-du
2. Normalization
a
Conversion of
selected sound
values
into Akkadian words
šumma awīlum īn mār awīlim u
ḫtappid īnšu uḫappadū
3.
English Translation b
Application of grammatical
rules
and definitions
"If a man
has destroyed the eye[sight] of another man,
they shall destroy his
eye[sight]." b
Note. Image composite, transliteration, normalization, and English translation by Boban Dedović. Cuneiform signs
redacted from Bergmann (1953, p. 26).
a Huehnergard (2013, p. 60) normalizes i-in-šu as īššu instead of īnšu, contra both Richardson (2004, p. 104) and
Roth (1995, p. 121). It is likely a misprint.
b The word "[sight]" is in brackets to indicate that the translation provided is ambiguous or otherwise uncertain.
Huehnergard (2013, p. 60) follows Roth's (1995, p. 121) reading of īn as "eye," contra Richardson's (2004, p. 105)
reading of "sight." The verb ḫuppudu is invoked twice, and the Chicago Assyrian Dictionary indicates that it is
attested mainly in the Law Code of Hammurabi as "to destroy."12 Both Huehnergard and Roth read it as "to blind."
Variants of the verb are also used in §198, §199, §218, §220, and §247. The verb is probably related to ḫepûm,
another verb that has eight primary translations in the Chicago Assyrian Dictionary.13
12 ḫuppudu: verb; to cause an eye injury, perhaps to blind (Roth et al., 1956, p. 240); in Roth et al. (1960, p. 154),
the translation for §196 reads "If a man destroys the eye of another man, they will destroy his eye."
13 ḫepû (ḫebû, ḫapû, ḫabû): verb; (1) to smash, destroy (an object); (2) to break (a tablet), to invalidate (a
document), to repudiate (an agreement); (3) to wreck, demolish, ruin; (4) to cut (wood trees); (5) to split in half,
divide (transitive and intransitive); (6) to break off; (7) to crush, injure, hurt; (8) to break into. (Roth et al., 1956, pp.
170–174).
EHAMMURABI.COM CASE STUDY 8
Preprint V.2.3.5
1.1.2. Access to Several Technical Publications
A second challenge to studying Akkadian concerns the quantity and technical difficulty
of required source materials. To unpack a given statute in the Law Code of Hammurabi, we
usually require three to five scholarly sources. This is because each of the three translation steps
noted previously require specialized publications. For instance, before making sense of a single
cuneiform sign, one must attain a publication that contains the transcription of those signs; that
is, a published book with drawings of the cuneiform characters. Here, the student or researcher
must choose a publication that concerns a given artifact. There are several options, and in each of
them the author may have transcribed the signs differently based on their interpretation. In many
cases, said authors must negotiate damaged artifacts, scribal errors, and a number of other
difficulties.14 Upon selecting a single publication that contains the signs for the Law Code of
Hammurabi, the student must then learn that very publication's annotation scheme. That is,
authors treating the same artifact may organize their signs according to different arrangements
and numbering methods. In our case, Bergmann's (1953) authoritative publication contains the
signs for §196. The author has even annotated the statute numbers. Despite this, Bergmann's
(1953) publication is intimidating because the author decided to write the front matter in the
Latin language.
To transliterate the cuneiform signs into English sounds, we require up to three separate
publications. To recall, a single cuneiform sign may have many sound or word values. Because
there are thousands of sign variations, we need a second publication called a sign list. These are
publications dedicated to cataloging cuneiform signs, their different form-factors, and associated
values. Two authoritative sign lists are that of Borger (2004) and Labat (1976). Both are hand-
written; the former is in German whilst the latter is in French. Moreso, these sign lists use
different annotation and numbering schemes. For example, the ma sign is number 552 in Borger
(2004, pp. 148–149), and number 342 in Labat (1976, p. 157). Yet another difficulty is added in
consideration of the fact that Akkadian has many loan words from Sumerian, which belongs to a
different language family. For Sumerian logograms, one may require a dedicated Sumerian sign
list or dictionary. In fact, the sole study of written signs is so complex with the result that it
14 As discussed later, §§66–99 in the Law Code of Hammurabi stele are almost completely destroyed. As a result,
brave scholars who endeavor to understand these contents must rely on additional artifact sources.
EHAMMURABI.COM CASE STUDY 9
Preprint V.2.3.5
belongs to its own field of study–orthography.15 That is, negotiating the sound values of
cuneiform signs requires publications produced by experts in a distinct subfield of study related
to Akkadian.
To normalize and translate an Akkadian sentence requires at least two more technical
publications: a grammar and dictionary. While Huehnergard's (2011) A Gramar of Akkadian is a
monument of mastery in describing the Akkadian language, the contents of its 650-plus pages
are highly technical and difficult to understand. Serious investigators also need access to a
comprehensive dictionary of Akkadian words and their meanings. The Chicago Assyrian
Dictionary composed by Roth et al. (1956–2011) is indeed thorough because it contains twenty-
one volumes in twenty-six individual books, and is thus a required source for many students of
Akkadian. It is also available to the public in the form-factor of PDF files. Notwithstanding,
using this dictionary is notoriously tedious because of its comprehensiveness. Moreso, it is worth
noting that it does not include any cuneiform signs themselves, owing partially to the fact that
dictionaries are a product of the field of lexicography.
1.1.3. Knowledge of Proprietary Information
The third challenging aspect of the Akkadian language is the necessity of proprietary
information. That is, one needs a certain degree of prior experience with both the cuneiform
writing system and translation process in order to understand the contents of §196 in the Law
Code of Hammurabi. In addition to everything noted above, we may highlight a few subtle albeit
complex nuances concerning the translation process and vetting sources. To recall, the three-step
translation process aforementioned indicated that transliterated sound values must be normalized
into coherent Akkadian sentences. In addition to determining word boundaries, the student must
comprehend the rules that govern this process. First, some of the transliterations contain
uppercase words, such as DUMU. This is because one rule dictates that logograms from the
Sumerian language are to be documented in this manner (Huehnergard, 2011, p. 108). Second,
the accent marks above some letters are short-hand notation for the sound's sign value number.
For example, u, ú, and ù are differentiated by means of the direction of the accent mark. The
letter 'u' without an accent mark means that it is one sign, ú means that it is the second, and ù is
15 Orthography concerns the study of writing with respect to spelling, symbols, and established usage. Some scholars
prefer to call it paleography or epigraphy, which concern the study of ancient inscriptions.
EHAMMURABI.COM CASE STUDY 10
Preprint V.2.3.5
the third; otherwise, a number or exponent is shown (Borger, 2004). Finally, when two sound
values contain adjacent vowels, they may produce an entirely new vowel. The manner in which
vowels fuse is governed by what are known as vowel contraction rules (Huehnergard, 2011, pp.
45–46). These are also a tricky enterprise, and only three examples of the kinds of proprietary
information required for understanding the contents of a given statute in the Law Code of
Hammurabi.
Finally, we must highlight the ambiguity of determining what an "authoritative source" is
in the first place. If one has formal training in Akkadian, the student's professors and educational
institution make that determination. However, such knowledge is not always widely publicized.
Moreover, students without formal training have many options to choose from. For instance, a
widely distributed version of the Law Code of Hammurabi is Harper's (1904) time-honored
publication. However, it is not widely known that Harper's work is largely defunct due to
advancements in cuneiform and Akkadian studies since the time of his publication. In fact, this
applies to many publications before 1990. While a simple rule of thumb may be only to use more
recent sources, this maxim is oftentimes unreliable. Rather, it is necessary to know in advance
the individuals, institutions, and publications of interest. Proprietary information of these kinds
may differ based on the artifact, date of publication, or other complex factors.
* * *
In detailing the process of translating statute §196 from Sumero-Akkadian cuneiform to
English, we highlighted three general challenges: the multi-step translation process, the need for
technical publications, and the requirement of proprietary information. These all represent
barriers to entry to the study of the Akkadian language. Other statutes in the Law Code of
Hammurabi are also more complicated than the example selected. In consideration of everything
noted above, it is apparent that achieving our original object of unpacking a single statute is
tedious. That is, it is not a simple business; and by means of these examples, we have thus
demonstrated that the study of Akkadian is complex.
1.2. Common Practices Amongst Existing Solutions
Let us suppose that a computer scientist is not trained in Akkadian, but nevertheless
wishes to construct a digital tool for others in order to study the linguistic contents of the entirety
EHAMMURABI.COM CASE STUDY 11
Preprint V.2.3.5
of the Law Code of Hammurabi. That is, our present object is to build a website that solves or
mitigates the severity of the challenges outlined in the previous section. Here, the scope of the
task has increased from a single statute to all 282. We thus begin by considering how others have
negotiated similar challenges. A formal review is required. This review includes a documented
list of existing tools alongside their pros and cons. In other words, we must evaluate the current
landscape of digital offerings. This is not unlike conducting a literature review for a formal
paper. Hereafter, we present evidence to demonstrate that existing digital tools have negotiated
the complexities of ancient languages by means of data aggregation, data granularity, and multi-
panel user interfaces. These tools seem to model the structure and format of intermediate-level
language-learning books intended for students of ancient languages like Akkadian.
1.2.1. Data Aggregation and Granularity
The most common practice applicable to the eHammurabi.com project is the manner in
which data are collected and organized. We may call these two distinct activities data
aggregation and data granularity. Data aggregation is the practice of combining contents from
multiple publications into a single digital experience. The finest example of this is perhaps Logos
Bible Study Platform by Faithlife (2023). It is a suite of digital tools that allows users to study the
Holy Bible. Because this ancient composition contains original sources derived from both ancient
Hebrew and Greek, it qualifies as a project that has negotiated complex ancient languages. In
sum, it allows you to read different versions of the Holy Bible alongside other resources, like
dictionary entries and scholarly commentary. They also offer tools in a wide variety of digital
form-factors: computer programs that must be installed, mobile applications for smartphones,
and a version accessible through an Internet browser. The Perseus Scaife tool by Scaife et al.
(2023) aggregates sources in a similar manner,16 albeit for classical texts in Latin and Greek. The
same can be said of the CDLI, or Cuneiform Digital Library Initiative (2023) for Sumerian and
Akkadian; the Chicago Homer website by Kahane et al. (2023); The University of
Pennsylvania's (2017) Electronic Pennsylvania Sumerian Dictionary; and many others. They all
aggregate information from multiple publications and offer it as a single digital tool.
16 As noted by Porter (2009), Ross Scaife's contributions to digital humanities were both legion and exemplary,
despite his untimely passing. He was a digital humanities pioneer that devoted his strength to classical texts.
EHAMMURABI.COM CASE STUDY 12
Preprint V.2.3.5
These aggregated data are then electronically stored in a granular manner in order to
deliver a more robust user experience. Data granularity refers to the degree of detail to which one
electronically stores information. Here, the Perseus Scaife tool by Scaife et al. (2023) noted
above is a fine example. For instance, when studying a specific passage in Homer's Iliad, users
can click on individual words in order to view its definition, grammatical form, statistical
frequency, English translation, and useful commentary. For the Perseus Scaife tool to do this, it
means that the developers undertook the task of electronically storing the original text from the
Iliad in a manner where each individual word can be isolated. The same can be said of several
other digital tools noted above. Although, the degree of detail may differ according to the
specific tool. Developers use these highly organized data in order to build rich features that
would not be possible otherwise.
1.2.2. Interactive Multi-Panel User Interfaces
The second most common practice is the adoption of an interactive multi-panel user
interface. That is, the interfaces of existing tools are broken up into sections that we may call
panels. Each panel contains data from one or more sources. For example, the Perseus Scaife tool
by Scaife et al. (2023) allows the user to view a given classical text's transcribed inscription, an
English translation, and other information in a vertical four-panel display (see Figure 2). Similar
features are implemented on the other digital tools noted previously, especially on the Cuneiform
Digital Library Initiative (2023) website. By populating multiple panels with different
information, users are then able to consume select contents from two or more publications. This
user interface design pattern proved to be a standard principle in all seventeen digital tools
reviewed as part of the present case study.
Interactive features are uniquely beneficial for digital tools because they oftentimes
exploit the benefits of highly structured data. As noted in the previous section, organizing data
from multiple sources allows the tool's creator to build unique features. That is, when the
practice of data aggregation is exercised alongside a multi-panel user interface, the number of
opportunities to create rich features increases. For example, the Perseus Scaife tool by Scaife et
al. (2023) has done the unclean work of digitizing classical texts such that each word is an
individual datum point.
EHAMMURABI.COM CASE STUDY 13
Preprint V.2.3.5
Figure 2
Multi-Panel User Interface Utilized by the 'Perseus Scaife' Digital Tool
Note. Image composite by Boban Dedović. Redacted from Scaife et al. (2023).
They executed the same degree of data granularity with respect to dictionaries of classical
languages like Latin and Greek. Now, therefore, this allowed them to associate each word of a
given text to one or more dictionary entries. As a result, upon clicking on a specific word in a
given panel, another panel may be populated with information about said word–all without
leaving the existing page. This is an example of an interactive feature; that is, functionality that
allows users to interact with the content instead of passively consuming it. More importantly, the
user does not need to rely on a separate resource to get more information about a given word.
1.2.3. Note About Print-Format Predecessors
Upon analysis of those digital tools noted above, it is made plain that they built upon
certain print-format predecessors. That is, the practice of data aggregation and multi-panel
display existed in traditional books. The best examples are those reading-class textbooks
EHAMMURABI.COM CASE STUDY 14
Preprint V.2.3.5
intended for intermediate-level learners of ancient languages. When one studies ancient
languages, the first few years are generally dedicated to studying the language's writing system
and grammar. Intermediate study then requires translating portions of passages from a wide
range of texts and authors. These are known as reading classes. The textbooks for these reading
classes seem to adopt a hand-holding approach by means of the following format: the exercises
for a passage contain a transcript, relevant definitions, and useful commentary. A fine example
of this is Ecce Romani III by Palma, Perry, & Lawall (2009), a reading class textbook for
students of Latin. For each translation exercise, those data noted above are aggregated and
displayed on the same page or pages, as shown in Figure 3, below:
Figure 3
Print-Book Arrangement of Contents in 'Ecce Romani III'
Note. Image composite by Boban Dedović. Redacted from Palma, Perry, & Lawall (2009, pp. 20–21).
This reduces the time it takes for the student to look up definitions and other useful information.
Another excellent example is Allen's (2015) Middle Egyptian Literature. This print book
contains literary texts in the Middle Egyptian language. For each text, Allen (2015) provides the
hieroglyphic symbols, their transliteration, an English translation, and commentary about verb
forms and other grammatical details (see Figure 4).
EHAMMURABI.COM CASE STUDY 15
Preprint V.2.3.5
Figure 4
Print-Book Arrangement of Contents in 'Middle Egyptian Literature'
Note. Image composite by Boban Dedović. Redacted from Allen (2015, pp. 65–66).
Reading class textbooks like the ones noted above have clear affinities with their digital
successors. For example, Ecce Romani III by Palma, Perry, & Lawall (2009) provides definition
entries for certain Latin terms that may be obscure. Instead of relying on the appendix or another
dictionary, students can understand the meanings of these terms in a matter of seconds, not
minutes. This is not unlike the Perseus Scaife tool's approach to classical texts. Both of these
resources contain aggregations of content displayed in panels. The user interface is thus
comparable between print-format predecessors and digital tools that treat ancient languages. The
main difference, however, is the fact that those print sources have limitations that cannot be
remedied unless a newer edition of the book is published. In contrast, digital tools can be updated
more rapidly. The differences are thus reflections of what the form-factor of print can provide
versus a digital counterpart; but the underlying pattern of data organization is almost identical, if
only on a conceptual basis. This suggests that digital tools focused on ancient languages have
built upon print resources by means of following common practices.
* * *
EHAMMURABI.COM CASE STUDY 16
Preprint V.2.3.5
Existing digital tools have negotiated the complexities of ancient languages via several
common practices. First, they practiced data aggregation, or the consolidation of multiple
publications into a single digital tool. They also practiced data granularity by means of
electronically storing information in small parts. Second, they displayed all those data in a user
interface that contains multiple content panels. Third, those tools that observed data granularity
were able to provide interactive features in order to display more information about a given word
or section of an ancient text. Finally, all these digital tools are comparable to the textbooks
intermediate students are required to use in language-learning reading classes. The
eHammurabi.com project therefore considered these practices as time-honored and effective.
1.3. Priorities of eHammurabi.com
The eHammurabi.com project sought to construct a superior digital tool for the Law Code
of Hammurabi in order to deliver an excellent user experience. We defined an "excellent user
experience" as one "that enables the user to accomplish a specific task whilst mitigating the
burdens of time commitment, prior experience, and emotional frustration." Our user task was "to
reduce the amount of time required to find a given statute's linguistic contents." That is, speed
was regarded as the highest priority. This was objectively measured by means of time spent
clicking and scrolling on the user interface. These priorities may be understood as an application
of three distinct arguments. First, eHammurabi.com must be both an aggregator and redactor of
several authoritative publications. Second, the website's user interface is its most important
aspect. Third, the user interface must be designed in accordance with a singular, measurable user
goal. The following paragraphs attempt to substantiate these arguments by means of explaining
how and why they were derived.
1.3.1. Task-Focused User Interface Design
The eHammurabi.com project prioritized the efficiency of its user interface design with
respect to a specific task we wanted users to accomplish. Let us begin by defining three core
terms that will be used repeatedly: (1) "user interface"; (2) "user experience"; and (3) "user task."
User interface design of a digital tool consists of the layout of the content, colors, imagery, font,
proportionality, and interactions when the user performs certain actions. The totality of these
design choices will produce what is called a user experience. A user task is a specific goal that a
user must accomplish by means of using the tool. For instance, the present case study was
EHAMMURABI.COM CASE STUDY 17
Preprint V.2.3.5
composed in Microsoft Word, which is a digital tool. The tool has a specific arrangement of
colors, sections, clickable elements, and so forth; and this is its user interface. The present author
is the user of Microsoft Word; and the user task was to compose, format, and distribute the
present case study. The process of using the tool to complete the task resulted in a user
experience, or assessment of how useful the tool was, or was not. Before developing
eHammurabi.com, we concluded that the user task, user interface, and user experience were
intimately related; and the user interface was the most integral component.
In speaking of digital tools more generally, the determination of a "good user experience"
seemed to be the most vague. That is, there seems to be no systematic, one-size-fits-all standard
for what makes a good user experience. Nevertheless, we find in our time that the more widely
used a piece of software is, the better its user interface tends to be; and, we infer that the better a
user interface is, the better the user experience should be. To substantiate this assertion, we
consider several notable examples. For example, Pew Research Center (2022, p. 33) reported
that as of 2022, over three out of four people in the countries surveyed own a smartphone. The
most widely used smartphone user interfaces are designed by two companies, Apple Inc. and
Google's parent company, Alphabet Inc. Whilst presenting the introduction of the first version of
Apple's (2007) iPhone,17 the late Steve Jobs noted that the device combined music, Internet,
email, and phone functionality "… to create the most revolutionary user interface since the
mouse.” Much of the entire keynote presentation at MacWorld 2007 was focused on describing
the manner in which the user interface of iPhone was easier and faster to use in comparison to
alternative options. On that very day, almost every user interface that preceded iPhone became
defunct. Today–almost fifteen years later–it is almost self-evident that the success of iPhone and
other smartphones is owed to the reduction of time it takes to complete tasks; and this is made
possible by the usability of said devices. If smartphones were not easy to use via superior user
interfaces, it is difficult to imagine how their popularity would increase to such a high percentage
of the population.
Digital tools designed to help users accomplish more complex user goals tend to be
harder to use because of the addition of complex features in the user interface. In the case of
Apple's iPhone, the goals were less complex in comparison to other examples. As noted, iPhone
17 For the entire video presentation, see the following YouTube link. https://youtu.be/vN4U5FqrOdQ
EHAMMURABI.COM CASE STUDY 18
Preprint V.2.3.5
combined music, Internet, email, and phone in order to simplify these operations. In comparison,
business productivity tools tend to have more complex user interfaces because their goals are
also complex. A basic example is Microsoft's suite of productivity software, which includes
Word, Excel, and PowerPoint. Each of these digital tools has a different user interface that
facilitates the completion of one or more user tasks that vary in complexity. For instance, making
a simple presentation in PowerPoint takes less time and expertise than making a financial ledger
in Excel. The degrees to which these tools are more difficult to use are thus predicated upon the
nature of the task to be accomplished. Accordingly, it follows that business productivity tools are
more difficult to use than smartphones because they require advanced features. Now, we may
compare all these tools to AutoCAD, a complex but robust software application for architecture
professionals. This application's user interface is more complex because the user's main task is
also extremely complex.
In sum, a piece of software's intended user goal, user interface, and user experience are
intimately related. That is, the goal of a piece of software should determine the features of its
user interface; whence it follows that the effectiveness of said features ought to predict the
quality of the user experience. The implications of this maxim are noteworthy. Mainly, it means
that building a digital tool like eHammurabi.com ought to proceed in a serial fashion: (1) define
the tool's purpose, or core user task; (2) design its user interface; and (3) measure the tool's
effectiveness with respect to its original purpose. Moreover, it means that the user interface is not
a trivial afterthought; rather, it plays a causative role in determining the quality of the user
experience. It follows necessarily that user interface design ought to be given a high station of
importance, as it was for the eHammurabi.com project.
1.3.2. The Importance of Design in Software
Having established that the user interface of a digital tool is important, it is necessary to
stress just how important it is. A simple example may illustrate this. If we compare the most
user-friendly toaster in contrast to its most unfriendly counterpart, we see the traditional impact
of product design. In most cases, the best-designed toaster is only incrementally better than the
most poorly-designed one. After all, toasters have standard features like slots for the bread,
buttons, levers, knobs, and perhaps a digital display. In other words, we may say that the user
experience of the worst toaster is rated as a one, and the best toaster a rating of 10. The degree of
EHAMMURABI.COM CASE STUDY 19
Preprint V.2.3.5
difference is incremental, and ultimately comparable. The same can be said of other appliances
and physical products in general, like cars. In our experience, this notion of incremental degrees
of difference does not apply to digital tools and software.
If we compare the best piece of software for a given task in contrast to its poorest
counterpart, the degrees of difference are exponential, not incremental. This is extremely
important. It means that if given two software applications intended to serve the same user goal,
the poorly-designed product can have a rating of one, but the best one can have a rating of 100.
This is difficult to appreciate unless you have experienced these degrees of difference. In such a
case, completing a given task takes a long time, requires excessive prior experience, and causes
emotional frustration. The best example of this is the design of an operating system for
computers. Before certain versions of Microsoft Windows and Apple's MacOS, computers had to
be used by means of a terminal. That is, starting a program required typing in specific
instructions in a text-only interface. This is in contrast to today's offerings–all of which utilize
what is known as a "graphical user interface" (see Figure 5). In those archaic systems, simple
tasks took longer, one had to memorize specific commands, and it is assumed that errors caused
frustration. We may thus declare it self-evident that the degree of difference between terminal-
based operating systems and graphical user interfaces is not incremental, but exponential.
Search engines are another more recent example of the importance of user interface
design. While many understand the user experience of using a search engine to be indicative of
today’s Google Search, we should do well to recall its then-dominant predecessors. Google
Search’s user experience was better by orders of magnitude in comparison to alternatives like
AltaVista. Since its earliest iterations, Google prioritized speed and relevance with respect to the
delivery of search results. That is, they wanted pages to load as quickly as possible; and be
populated with the most appropriate results based on the user's intention in the search query.
Even with slower computers, Google Search delivered this in less than half a second.18 This may
be compared with its then-competitors: their pages took several seconds to load, distracted the
user with a pop-up advertisement for a given period of time, and served the user with results that
were oftentimes irrelevant.
18 As of this writing, Google Search's search engine result pages still prominently list the query's processing time.
EHAMMURABI.COM CASE STUDY 20
Preprint V.2.3.5
Figure 5
Screenshots of Terminal vs. Graphical User Interfaces: MS-DOS vs. Windows
Note. Image composite by Boban Dedović. Redacted from MS-DOS (2012) and Windows 1.0x (2015). While the
graphical user interface shown on the bottom may seem archaic, it was a revolutionary innovation that gained
widespread adoption amongst software companies and developers.
EHAMMURABI.COM CASE STUDY 21
Preprint V.2.3.5
The time it took to get certain information by means of a search query was therefore
exponentially different between Google Search and its predecessors. That is, the degree of
difference between the user experience of Google Search and others was not on a scale of 1–10,
as it is with most physical products. Rather, it was on a scale of 1–100; and this maxim applies at
present. Because the user experience is facilitated by the user interface's ability to accomplish the
user's desired task, we are therefore inclined if not obliged to regard user interface design as a
uniquely important aspect of many if not all digital tools.
1.3.3. Defining an "Excellent" User Interface
It remains to apply those priorities noted above unto the task at hand—delivering an
excellent user experience for finding certain statutes in the Law Code of Hammurabi. We have
already remarked that a good user experience reduces the time it takes to complete a task, does
not require much prior experience, and minimizes emotional frustration. Accordingly, we began
by defining our core user task; or, what it is that we wanted users to accomplish on the
eHammurabi.com website. We defined our user task as follows: "allow users to view
authoritative cuneiform signs, transliterations, normalizations, and English translations for a
given statute as quickly as possible." This goal was selected for two reasons. First, it was easily
measurable via units of time, and could thus serve as an objective standard. Second, it seemed to
resolve the outstanding challenges we observed with the current state of affairs.
The nature of our defined user goal was measured objectively via two metrics: the total
number of resources required to display desired contents; and the time it took a user to find said
contents. The first metric considered the advantages of data aggregation. In a print-only setting,
this would mean trying to reduce the number of books utilized. In a digital context, it meant
aggregating data from those very publications in order to display them in a single user interface.
We extended this maxim furthermore by considering the time it would take to navigate contents
within our digital tool as well. That is, we did not want users to have multiple instances of the
Electronic Hammurabi tool open in order to view a given statute. In a website context, this
meant reducing the number of browser tabs open at once. The second metric was broken down
into three time-consuming operations: (1) how long it takes for the page to load; (2) the number
of clicks it takes; and (3) the time it takes to scroll. These were selected because of their
simplicity. Finally, it was necessary to consider the impact of different devices. For instance,
EHAMMURABI.COM CASE STUDY 22
Preprint V.2.3.5
desktop and laptop computers have different screen sizes in comparison to tablets and
smartphones. We thus resolved upon three device categories–computers, tablets, and
smartphones–each of which were regarded as a separate user experience.
* * *
In establishing the priorities of the eHammurabi.com digital tool, we have argued three
points: first, that eHammurabi.com must aggregate and redact data from multiple sources;
second, that the user interface is the most important component of the project; and third, that the
design of the user interface must focus on helping the user accomplish a specific task. The user
task of interest was as follows: "to reduce the amount of time required to find a given statute's
contents in the Law Code of Hammurabi." This user goal was integrated into what we defined as
a good user experience: that is, one that "enables the user to accomplish a specific task whilst
mitigating the burdens of time commitment, prior experience, and emotional frustration." These
priorities built upon the common practices established in the previous section; and were refined
furthermore based on our analyses of the relationship between a digital tool's "user experience,"
"user interface," and "user task." In sum, we concluded that eHammurabi.com ought to prioritize
defining a user task before designing a user interface, and in turn this would help us deliver an
excellent user experience.
2. Development and Execution
2.1. Prototypes of Electronic Hammurabi
Technical development of the eHammurabi.com project began with prototyping; that is, a
procedure whereby experimental form-factors of the digital tool are quickly assembled in order
to evaluate their effectiveness. To create said prototypes quickly, web-based spreadsheet
software was selected–Google Sheets in this case. We thus began by experimenting with
different layouts of several statutes within the Law Code of Hammurabi. Next, we asked
individuals to navigate to certain statutes upon being given various initial pieces of data: the
statute number, the topical contents of the statute, or a key word. Upon analysis, the following
user interface features allowed users to navigate to a given statute more quickly than other
features: a single page with vertical scrolling for all 282 statutes; a left-side navigation menu
EHAMMURABI.COM CASE STUDY 23
Preprint V.2.3.5
with a list of all statute numbers grouped by a descriptive title; and a four-panel vertical display
to show the desired contents side-by-side; see Figure 6, below:
Figure 6
Screenshot of an Early Prototype of eHammurabi.com Created in Google Sheets
Note. Image created by Boban Dedović. Mockup created using Google Sheets.
2.1.1. Layout and Single-Page User Interface
We determined that a single-page interface was most conducive to our goals. This
decision was based on a surprising revelation. Upon locating a single statute, users would
oftentimes continue scrolling downwards to the next statute. This is largely because the contents
of each statute usually have a topical relationship with those statutes adjacent to it. For example,
§138 concerns how much a man has to pay his wife if he wishes to divorce her; and §139
determines the price in the event that the previous statute's conditions are not applicable. It is
thus not uncommon for adjacent statutes to be related to one another in a meaningful way. By
EHAMMURABI.COM CASE STUDY 24
Preprint V.2.3.5
allowing users to keep scrolling up and down, the contents of relevant statutes could be accessed
more quickly. In contrast, a multi-page design would have required users to navigate away from
the initial statute or have two instances open at once. A single-page design thus saved time.
Moreover, users reported frustration over having to scroll horizontally. That is, if the
content overflowed on the page in the left or right direction, user sentiment was negative. Some
users even reported emotional frustration because of it. We thus resolved that scrolling in a
single direction–up and down–was the appropriate design choice. We ensured that all of the
contents fit into the user's screen size. However, this inadvertently created two new problems.
First, users spent lots of time scrolling up and down the single page. This was because putting all
282 statutes on a single page took up lots of space. On mobile devices, in particular, the
excessive scrolling was a unique challenge. Second, page load times became a problem once it
was populated with all of the cuneiform signs. That is, the time it took for the page's contents to
load was much slower as a result of the single-page user interface.
2.1.2. Persistent Left-Side Navigation Menu
Navigation to and from statutes located far apart was resolved by means of a persistent
left-side menu that listed all of the statute numbers. It was essentially a mini-index of the entire
Law Code of Hammurabi. Once users were able to click to a given statute number, the time cost
of scrolling diminished quickly. Before we implemented the menu, users scrolled aggressively
before stopping to read the number of the statute they were looking for. After implementation,
users simply clicked on the statute number and the interface scrolled to its location within less
than half a second. This time delay was intentional.19 Once users became acclimated to the
navigation menu, navigating from §1 to §282 could be accomplished in less than five seconds.
19 The reason we intentionally implemented a 320-millisecond delay following the click is interesting, if not
remarkable. Initially, users would see the statute they clicked on almost instantaneously after clicking its number in
the left-side menu. However, many users kept pressing the link without noticing that the page's main panel contents
had changed. It seemed to us that the processing speed was actually a hinderance, owing to the fact that many users
did not perceive the change. By adding a 320-millisecond smooth-scrolling effect upon each click, the motion
seemed to alert the user that some change had happened; and this mitigated the confusion. So, adding an intentional
time delay between clicks on the left-side navigation and the display of content in the main panel actually made the
user experience faster on the whole.
According to Google's (2023) Material Design guidelines, motion of elements in the user interface is an important
cue that the button they clicked on worked. Moreso, because human visual perception is most clear in a tiny area of
a normal person's visual field, subtle changes to contents in the peripheral areas of the visual field are more likely to
EHAMMURABI.COM CASE STUDY 25
Preprint V.2.3.5
With the addition of the navigation menu, a new problem emerged: users struggled to
locate statutes according to their topic. To remedy this, we implemented headings in the same
left-side navigation menu (see Figure 7). These heading titles summarized the contents of a
group of statutes. We called these "cluster headings" because the content of the title was
representative of a group, or "cluster," of statutes. Determining what these titles should be was
not difficult because most prior publications did the same. Accordingly, we compared and
contrasted five of them in order to determine our own. For example, the first five statutes were
represented with the following heading: "§1 - §5: Unsubstantiated allegations." We derived this
specific heading from Richardson (2004, p. 25). To compare, Abulhab (2017, p. iv) titled these
same five statutes "Courts and Judiciary Affairs." We avoided composing long cluster headings
so that they could fit into one single line of text. This was effective in reducing the time it took
for users to identify a given statute according to the topic.
2.1.3. Multi-Panel Main Body Display
The main section of the most effective prototype ultimately displayed four vertical side-
by-side panels: (1) an image of the cuneiform signs; (2) transliteration; (3) normalization; (4)
English translation. Initially, we experimented with organizing the four contents of each statute
horizontally. This arrangement followed the print publication by Abulhab (2017). While
Richardson's (2004) publication also followed a horizontal arrangement, this author grouped the
statutes in their normalized form, and then their English translations. Oftentimes, each of these
groups were located on separate pages. This meant that users had to go back and forth between
two pages in order to find a single statute. We wished to avoid this because it would have taken
more time for users to accomplish our pre-defined user task. See Figure 7 for an image of the
final version of the user interface, as well as detailed descriptions.
Choosing to display content in vertical panels instead of horizontal ones was an
important decision point because of its impact on the overall length of the entire page. Initially,
horizontal panels made sense because they reduced the amount of excess white space produced
by a vertical arrangement.
go unnoticed. We thus concluded that users did not perceive the content in the main panel of the website because it
happened too fast. When we asked our early testers about this explanation, most of them agreed.
EHAMMURABI.COM CASE STUDY 26
Preprint V.2.3.5
Figure 7
Mockup of Vertical Multi-Panel User Interface of eHammurabi.com
Note. Image created by Boban Dedović. Mockup created by Boban Dedović using https://moqups.com, an excellent
tool that is both easy to use and accessible without cost. The shown arrangement of panels only applies for wide-
screen computers. The left-side navigation menu and other contents are programmed to change size and location
according to the screen sizes of tablet and smartphone devices. This important matter is taken up in a later section.
1. Persistent left-side navigation: The menu is always visible and has a separate scrollbar from the main display.
2. Main-body display: The main display contains four vertical sub-panels. These sub-panels contain the content for
each statute from left-to-right: cuneiform signs, transliteration, normalization, and English translation.
3. Persistent header: This header is always visible and labels the content type of each sub-panel in the main display.
4. Statute header: This header lists the statute number and acts as a separator between them. It indicates that the
contents below it correspond to said statute.
5. Statute source: The source title of the contents in the sub-panel includes the author's last name, year of
publication, and page number. For the cuneiform signs, the column and line numbers are also shown.
6. Statute content: The cuneiform signs sub-panel includes an image, and the rest contain text.
7. Cluster header: This header describes the topical nature of the statutes listed below it. It also acts as a separator.
8. Statute links: Each number is a link that corresponds to one of the 282 statutes. Clicking on one scrolls the main
body display so that the statute number's contents are displayed within the viewport of the user's browser screen.
EHAMMURABI.COM CASE STUDY 27
Preprint V.2.3.5
That is, less unutilized space meant that the single page was shorter; in turn, this reduced
scrolling. However, our findings suggested that most users relied on the English translation in
order to orient themselves, then proceeded to shift attention to the other three form-factors of the
statute. While a horizontal arrangement did reduce unused space, the time spent locating the
English translation effectively negated the time saved. In contrast, the vertical arrangement
allowed users to scroll down through English translations of each statute much more quickly. In
following the user interface of the Perseus Scaife tool by Scaife et al. (2023), we resolved that
the time spent scrolling due to excess white space in a vertical arrangement was negligible. The
extra white space made the left-side navigation menu described previously an essential aspect of
the user interface. Additionally, the original Akkadian inscription was organized in vertical
columns. This meant that to implement a horizontal arrangement of the signs required cropping
each column into one image per line, which would have been much more work.
* * *
Initial prototypes of the eHammurabi.com website experimented with different layouts.
We asked users to locate statutes and measured the time it took for the page to load, and for them
to click and scroll. We determined that a single-page inclusive of all 282 statutes was sufficient;
and a left-side navigation menu alleviated the problem of excess scrolling. Any of the 282
statutes were accessible within less than five seconds. The main body was organized into four
vertical panels. These prototypes were assembled quickly using Google Sheets.
2.2. Data Sources and Data Structure
The second step of developing eHammurabi.com required aggregating data from
excellent sources and organizing it in an electronic format conducive to our user task. All of
these data came from five sources (see Table 2). We considered publication dates and the
notoriety of each scholar in choosing these sources. The final aggregation of data required
mixing and matching contents from each; in total, this included 4,233 individual datum points.
The structure of our dataset reflected a sufficient degree of data granularity for the task at hand,
and was four levels deep: statute number > content type > source > source content.
EHAMMURABI.COM CASE STUDY 28
Preprint V.2.3.5
2.2.1. Determination of Authoritative Sources
Populating the user interface with content required gathering authoritative versions of the
Law Code of Hammurabi in order to mix and match the best contents of each. Ideally, we sought
to identify a single publication that had all four required contents for each statute, as noted: the
cuneiform signs, transliteration, normalization, and an English translation. The ideal publication
was thus The New Complete Code of Hammurabi by Viel (2012). In fact, the publisher's
description of the book indicates that Viel (2012) produced the publication in order to alleviate
the challenges we have treated in the present work:
"While several translations, transcriptions, and handwritten illustrations of the Codex already exist, anyone
attempting to deal with the theme in all its aspects will find it necessary to leaf through several books,
which is not only a confusing exercise but also expensive."
Viel's work even includes additional translations of the work in Neo Assyrian, which is a latter
dialect of the Akkadian language. Despite this, the book is out of print and there do not seem to
be any digital versions in circulation. Accessing the work required visiting the few libraries that
had them, and oftentimes it could not even be borrowed.
Another viable option that consolidated the cuneiform signs, normalization, and
translation was Harper's (1904) time-honored work. However, this was problematic. First,
Bergmann's (1953) signs were more recent, and thus believed to be more authoritative. Second,
Harper's work did not include the transliteration. Third, advancements were made with respect to
the study of the Akkadian language since Harper's initial publication. That is, more recent
publications took advantage of said advancements. For example, the title of Harper's (1904) book
indicates that the dating of the artifact is 2250 BCE. However, recent findings have determined
that the date of the artifact is more likely 1750 BCE, as both Huehnergard (2011, pp. 160–161)
and Roth & Michalowski (1995) noted. Moreso, humanity's knowledge of Akkadian grammar
was immature in 1904 in comparison to after 2010. As a result, Harper's (1904) normalizations
and English translations were no longer authoritative. Thus it came to pass that the content for
each aspect of the Law Code of Hammurabi would have to be sourced from other publications.
The bulk of eHammurabi.com derived its contents from three publications: Bergmann's
(1953) signs, Huehnergard's (2011) A Grammar of Akkadian, and Huehnergard's (2013) answer
key for the same. To begin, Huehnergard is considered by many to be the world's foremost
EHAMMURABI.COM CASE STUDY 29
Preprint V.2.3.5
authority on Semitic languages like Akkadian. His contributions are internationally known and
respected. Also, courses in Akkadian at the University of Chicago recognize Bergmann (1953) as
the standard text; the same is said of Huehnergard's (2011) grammar. Because of the University
of Chicago's high station of prominence in the study of Akkadian, we resolved that the works of
those two scholars were authoritative.
2.2.2. Multi-Source Data Aggregation
We computed that combining the works of Bergmann (1953), Huehnergard (2011), and
Huehnergard (2013) provided over half of the contents required for the eHammurabi.com
website. To illustrate, in Huehnergard's (2011) grammar, he provides exercises for students.
Some of these include statutes found in the Law Code of Hammurabi. In some of these instances,
the author provided signs derived from Bergmann (1953); in others, Huehnergard (2011)
provided his own transliteration and asked students to normalize them; in others, he provided a
normalization and asked students to translate them. The answers to these exercises are located in
Huehnergard's (2013) own answer key. For instance, let us consider §101: the signs are in
Bergmann (1953, p. 12); the transliteration is in Huehnergard (2011, p. 441); and both the
normalization and English translation are in Huehnergard (2013, p. 123). Thus it came to pass
that we were able to locate all required contents for this statute. When we aggregated these data
for all available statutes, the compilation accounted for almost 60% of the entirety of the Law
Code of Hammurabi. The remainder was sourced from Abulhab (2017) and Richardson (2004).20
We may remark that aggregating these data from multiple source publications produced
some minor inconsistencies. For example, it was not uncommon for Abulhab's (2017)
transliteration to differ from the normalization that others provided. In many instances, the
difference was based on the author's interpretation of logograms. As noted, logograms represent
entire words; and some of these have many potential options. In any case, we remedied this by
20 For the normalizations and English translations, we selected Richardson (2004) over the excellent compendium
provided by Roth & Michalowski (1995) for several reasons. First, several important developments relevant to the
Law Code of Hammurabi came to pass between 1995 and the present day. One example concerns the translation of
the phrase "DUMU awīlum." This phrase was thought to denote a social group within Akkadian society, as in "a
member of the awīlum class." However, more scholars now believe that it is reasonable to translate "DUMU
awīlum" simply as "man," or "gentleman" in the case of Richardson (2004, p. 220). Second, Richardson (2004)
devoted a significant portion of his preface and footnotes to consideration of Roth's (1995) interpretations. Finally,
Professor Roth was kind enough to expound upon some of the aforementioned considerations during lectures on
Mesopotamian Law at the University of Chicago in 2021.
EHAMMURABI.COM CASE STUDY 30
Preprint V.2.3.5
means of ensuring that at least the normalization and English translation came from the same
author or source. To illustrate, Richardson (2004) provided normalizations and translations for
the entire Law Code of Hammurabi. So, if Huehnergard's two publications did not have both of
these contents, we used Richardson (2004) instead.
Table 2
Data Aggregation Content Summary for eHammurabi.com
Source publications
Content types
Cuneiform Transliteration Normalization
Translation
Bergmann (1953)
246
-
-
-
Huehnergard (2011)
-
145
-
-
Huehnergard (2013)
-
44
189
189
Abulhab (2017)
-
59
-
-
Richardson (2004)
-
-
60
60
Note. Data compiled by Boban Dedović. The total number of statutes is not 282 because §§66–99 are damaged.
2.2.3. Data Scope, Architecture, and Granularity
Any given statute required collecting seventeen individual datum points; and this totaled
up to 4,233 individual fields for the entire Law Code of Hammurabi. The core datum unit was
the statute number, which we have already remarked was a range between 1–282. Within each
statute, four sub-groups of data were required: cuneiform signs, transliteration, normalization,
and English translation. For the cuneiform images, we required an image file from the original
publication, the column and line number reference, and the page numbers. For each of the other
three content types, we required the source's name, the raw text, and the page number. When
compiled, this meant that each statute required seventeen pieces of information in order for it to
be complete. Taken to completion, eHammurabi.com required up to 4,794 individual datum
points (17 * 282 = 4,794). But, because §§66–99 are heavily damaged in the original artifact, we
decided to exclude these statutes from the initial version of the website. Accordingly, this
reduced the scope of our dataset by 561 datum points, leaving us with the final count: 4,233
individual fields.
EHAMMURABI.COM CASE STUDY 31
Preprint V.2.3.5
From the data scope described above, we may now consider its impact from an
information architecture standpoint. While the term "information architecture" can be used in
many ways, for our purposes we consider chiefly the manner in which our data are organized.
This is important because how one arranges data causes implications. This is true whether the
organizer intends to or not–it cannot be helped. To begin, let us visualize the information
architecture of eHammurabi.com as a simple tree diagram, shown below in Table 3:
Table 3
Four-Level Information Architecture Tree for eHammurabi.com's Dataset
Level
-1
Level
-2
Level
-3
Level
-4
Statute number (282)
§§1–282
Content type (4)
Cuneiform signs
Transliteration
Normalization
Translation
Source (5)
Bergmann (1953)
Richardson (2004)
Huehnergard (2011)
Huehnergard (2013)
Abulhab (2017)
Content (3)
Page number
Column/line number a
Text or image
Note. Created by Boban Dedović.
a This datum point was only required if the content type was "Cuneiform signs" and the source Bergmann (1953).
As shown, our information architecture is hierarchical in nature, and four levels deep. The first
level is the statute number and ranges from 1–282. The second level represents the content type,
and is thus limited to four options: cuneiform signs, transliteration, normalization, and English
translation. The third level represents the source, which had five options. The fourth level has
three fields that range from text and number values. This organization was selected because of its
simplicity; and proved sufficient to execute our user goal. Notwithstanding, this arrangement was
not without consequence, as shown next.
The eHammurabi.com project's data scope and granularity approach was a prohibitive
factor with respect to the feasibility of building certain advanced features. As noted in the
Introduction and Background section, data granularity refers to the degree of detail to which one
has organized their data. In our case, the level of detail was suitable for a minimal viable version
EHAMMURABI.COM CASE STUDY 32
Preprint V.2.3.5
of the eHammurabi.com digital tool. To illustrate how our data scope has consequences, let us
suppose that we want to build the following feature: when a user clicks on a word in the
normalization, we want to place a box around its corresponding cuneiform sign values. Given the
data granularity we determined above, such a feature would be just shy of impossible to
implement. This is a consequence of information architecture. Simply put–we neither collected
nor organized those data necessary in order to build such an interactive feature. Because the
cuneiform signs are whole images, we have no information about the location and content of
individual signs. Even if we did, we have no data to assign a relationship between one sign to its
corresponding normalized word. To implement such a feature, the architecture of our data would
probably need many more additional data fields. Thus it came to pass that data granularity had a
profound impact on the feasibility of building advanced interactive features.
* * *
Our findings determined that Bergmann's (1953) signs, Huehnergard's (2011) grammar
book, and Huehnergard's (2013) answer key provided over half of the contents required for
populating the eHammurabi.com website. The works of Abulhab (2017) and Richardson (2004)
contained the rest. These sources were sufficiently authoritative. Roughly 4,200 individual pieces
of datum were required in order to include the cuneiform signs, transliterations, normalizations,
and English translations for each statute in the Law Code of Hammurabi. Our data structure was
four levels deep, which provided sufficient data granularity for the project's user goal.
2.3. Developing eHammurabi.com
The execution of eHammurabi.com required selecting a form-factor for the digital tool,
selecting a storage method for the data, coding the user interface, and filling in some remaining
gaps. We decided to construct a web application accessible from a browser instead of a
downloadable computer application. The data for each statute were electronically stored in a
format called XML. The user interface relied on freely-available technologies, and followed the
design principles of Google's (2023) Material Design. We rearranged contents for different
screen sizes to accommodate smaller tablet and smartphone devices. Finally, to reduce the need
for prior experience, we wrote an introduction to the single website page that explained how to
read the contents in plain English. That is, we provided background information about the
artifact and explained the three-step translation process described previously.
EHAMMURABI.COM CASE STUDY 33
Preprint V.2.3.5
2.3.1. The Benefits of Responsive Website Applications
The eHammurabi.com project was built for the web because of three main benefits:
accessibility, versatility, and maintainability. Website applications are more accessible to more
users and devices in contrast to other options. Traditional computer software requires building an
application for a specific operating system like Microsoft Windows or Apple MacOS. Then,
users have to download an installer file and run the application. If the Electronic Hammurabi
digital tool followed this approach, providing access to more users would have required building
more than one version of the same tool. Plus, these native computer applications would only be
accessible via a laptop or desktop computer. This was problematic for two reasons. First, it
would have required a duplication of efforts in complex technologies. Second, users would have
been unable to consume the content from a smartphone device unless we built dedicated mobile
applications. In contrast, website applications are accessible via Internet browsers. Almost all
major Internet-enabled devices have a browser, including smartphones. Thus it came to pass that
a website-only version was a robust means of ensuring the tool was accessible to the public.
Website applications are also more versatile from a development standpoint. That is,
building for the web is faster, cheaper, and extensible. In most cases, building a website takes
less time than building a traditional computer or mobile application. There are many companies
that provide do-it-yourself website-making tools. This option was cheaper too. Most websites on
the Internet are built upon open-source technologies. This means that anyone can download or
modify such technologies in order to use them. This is oftentimes untrue when building
applications for operating systems such as Microsoft Windows or Apple iOS. That is, these
companies may require one or more recurring fees in order to be listed in their respective digital
application stores.
Finally, website applications like eHammurabi.com are easier to maintain and update.
Changes made can be deployed to all users almost instantaneously because it has a single
codebase hosted on a web server. This is an important benefit because developers can focus on
improving the website instead of dealing with other issues like software compatibility.
Deployment to other platforms is also easier. For example, let us suppose that we wish to deploy
eHammurabi.com in a form-factor closer to the look and feel of a mobile application.
Smartphone Internet browsers allow for the installation of a single website as an individual
EHAMMURABI.COM CASE STUDY 34
Preprint V.2.3.5
application icon. This option is available for free and bypasses application stores. Issues related
to performance or loading times can also be mitigated because of advancements in technology
related to caching–or the storage of data on local devices. When building a website application,
transitioning to traditional computer or mobile applications is also easier.21
2.3.2. Data Storage Method and Core Technologies
Storing the content in an XML file format was selected over using a traditional database
or another file format. If one wishes to store data electronically, there are several options. Each
option has pros and cons. For example, traditional relational databases are simple, flexible, and
secure. However, the database itself is an additional piece of software that requires more
programming code alongside a separate user interface to input or modify those data. Conversely,
data may be stored in text files. XML data storage utilizes Extensible Markup Language, which
is a markup language that allows one to define and structure data. Programming languages such
as PHP or others are then able to access the data contained in those files in order to display them
in the user interface. Figure 8, below, provides the first 39 lines of our XML file. Each statute
required 33 populated data fields in order to be complete.
21 For example, there have been exciting new developments with respect to Progressive Web Applications (PWA).
These are website-based applications built upon freely available technologies like HTML, CSS, and JavaScript; and
they are designed to work smoothly on any operating system or platform that includes a standards-compliant web
browser. They can take advantage of caching features in order that data are loaded and stored on local devices. This
makes PWA tools usable on devices even when there is no internet connection. One of many use-cases includes the
ability to make a native mobile application for Apple's App Store or the Google Play Store without coding
everything from scratch. This can be accomplished by means of creating a basic mobile application that runs an
instance of the operating system's web browser upon launch; which then serves a given website's content. If the
website has implemented PWA capabilities, the website's contents are stored locally on the user's device. As a result,
there is little loading time when using the mobile application and it also works without an internet connection. The
options for integrating PWA-capabilities into a website are widely available and usually free. Notwithstanding, these
technologies are rather immature and subject to rapid change; and, such solutions may not be appropriate for all
digital projects. If considering implementing a PWA, one should therefore do well to research the available options
and proceed with caution.
EHAMMURABI.COM CASE STUDY 35
Preprint V.2.3.5
Figure 8
XML Data Structure for eHammurabi.com's Dataset
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
<?xml version="1.0" encoding="UTF-8"?>
<LawCode>
<Codes>
<Code>
<CodeNum>1</CodeNum>
<Group>1</Group>
<Status>1</Status>
<Cuneiform>
<Bergmann>
<Page>4</Page>
<Col>V</Col>
<Lines>26-32</Lines>
<ImgSrc>law_1.jpg</ImgSrc>
</Bergmann>
</Cuneiform>
<Translit>
<HAG3>
<Page>277</Page>
<LineText>šum-ma a-wi-lum a-wi-lam ú-ub-bi-ir-ma n-er-tam e-li-šu
id-di-ma la uk-ti-in-šu mu-ub-bi-ir-šu id-da-ak
</LineText>
</HAG3>
</Translit>
<Norm>
<HKey>
<Page>64</Page>
<LineText>šumma awīlum awīlam ubbir-ma nērtam elīšu iddī-ma lā
uktīššu, mubbiršu iddâk
</LineText>
</HKey>
</Norm>
<Translate>
<HKey>
<Page>64</Page>
<LineText>If a man accused a man and laid (a charge of) murder
against him but has not convicted him, his accuser
will be executed.
</LineText>
</HKey>
</Translate>
</Code>
</Codes>
</LawCode>
Note. Image created by Boban Dedović. The black text represents the syntax of XML format, which allows you to
define unique names for your data fields. We tried to keep these short. That is why "HAG3" was used as an acronym
for "Huehnergard's Akkadian Grammar, 3rd edition." The green text represents the actual data. We may remark
that the structure of the XML file does not have to match the four-level data architecture described previously.
Additionally, fields like <group> and <status> were necessary in order to track completion and assign topic groups.
EHAMMURABI.COM CASE STUDY 36
Preprint V.2.3.5
As shown, the XML data structure for the eHammurabi.com project defines the kinds of
information required for each statute. XML was selected because the data are small in size and
hierarchical in nature. Plus, editing a single file was easier than implementing database software
and using another user interface for data entry. The final XML file for eHammurabi.com was
almost 10,000 lines long. Other file formats similar to XML can accomplish the same object.22
The domain name ehammurabi.com was purchased from Google Domains for a low cost.
The hosting provider was HostGator, another inexpensive albeit robust option. We elected not to
use a content management system like WordPress or others because of the single-page nature of
the website. To point the website address to the HostGator server, we utilized a technology
called Cloudflare. Cloudflare is a Domain Name Service provider–or DNS for short. This tool
has a free plan and also provides security and performance features. That is, it makes the website
load fast in addition to many other benefits. The website itself relied on a programming language
called Hypertext Preprocessor–or PHP for short. It allowed us to write code that accessed the
data contained in the XML file in order to present it to the user via their browser. Less than 100
lines of code allowed us to write a "foreach loop" algorithm to display all 282 statutes of the Law
Code of Hammurabi. That is, for each statute in our XML file, the algorithm instructed the
browser to show those data that we wanted to display. Styling was done using Cascading Style
Sheets (CSS) syntax, which is a language that allows you to modify the presentation of data.
2.3.3. Designing a User Interface for Multi-Device Consumption
The user interface utilized Google's (2023) Material Design framework. Material Design
is a guide for designing user interfaces according to specific principles, or best practices.23 For
example, one principle states that user interfaces ought to prioritize "content over chrome." That
is, there should be more focus on the information itself, and distractive elements should be
avoided. Consequently, we selected a monochrome color palette: white, black, and grey. Less
important contents were also smaller and lighter. Several other freely available technologies
were relied upon in order to launch the alpha version of eHammurabi.com in February 2021.
22 A popular format is JavaScript Object Notation, or JSON. Free tools can convert XML to JSON quickly.
23 According to Google (2023), "Material Design is an adaptable system of guidelines, components, and tools that
support the best practices of user interface design. Backed by open-source code, Material Design streamlines
collaboration between designers and developers, and helps teams quickly build beautiful products."
EHAMMURABI.COM CASE STUDY 37
Preprint V.2.3.5
Following launch, it was necessary to make significant adjustments to the user interface
in order to account for mobile and tablet devices. Website applications are beneficial because
they are accessible by any device with an Internet connection and browser. As noted, however,
this also meant that the user interface was of a triple quantity. That is, smaller screen sizes of
both tablets and smartphones required a partial duplication of efforts. The main challenge of
executing a mobile-friendly experience was the density of data contained in the Law Code of
Hammurabi. To remedy this, we wrote style rules to change the user interface based on the
dimensions of the user's device. This is known as responsive design. For tablets, we collapsed
the three right-most panels into a single panel. For smartphones, we moved the left-side
navigation menu off-screen and allowed users to access it with the click of a single button that
was persistently shown on the bottom of the page. While these modifications did impact how
long it took users to locate a given statute, it could not be helped.
* * *
The final version of eHammurabi.com consisted of a website application that accessed
data from a single XML file. We decided that a web application was the best form-factor of the
digital tool because more devices have Internet browsers. This provided more accessibility in
contrast to other options; and was easier to modify and improve from a development standpoint.
To accommodate different screen sizes like tablets and smartphones, we had to change the user
interface for each device. Google's (2023) Material Design kit was utilized alongside other freely
available technologies.
3. Results and Discussion
3.1. Satisfactory Results
The internal results and external adoption of the eHammurabi.com project were agreeable
to our goals. Internally, we were interested in making sure that individuals could navigate to a
statute as quickly as possible without having to use external resources. A user study was
conducted whereby we measured how long the same task took in print format, digital PDF
format, and eHammurabi.com. On average, users found contents almost ten times faster while
using eHammurabi.com in comparison to searching through PDF files. Externally, we were
interested in evaluating whether the public would use the digital tool. Between April 20 to May
EHAMMURABI.COM CASE STUDY 38
Preprint V.2.3.5
20, 2023, we received over 120,000 website requests and over 3,000 unique visitors. Wikipedia
editors and YouTube channels began using the website as a reference tool. Our interpretation of
these results is that the problem we tried to solve was shared by many other people; and that the
website grew in popularity because it was convenient, properly cited, and easy to use.
3.1.1. Internal Results
Internal data show that the eHammurabi.com project effectively reduced the amount of
time required to locate a single statute by orders of magnitude in comparison to alternative
options. To determine this, a user study was conducted. We asked nine undergraduate college
students from the Chicago metropolitan area to meet in-person. All participants were screened to
ensure two things: first, that they had no prior experience with the Law Code of Hammurabi; and
second, that they had basic computer literacy skills. Then, we asked them to look up nine pre-
selected statutes from the Law Code of Hammurabi in three form-factors: print books, digital
PDF files on a laptop, and eHammurabi.com.
For each form-factor, we allowed users to browse the contents on their own for twenty
minutes and answered any questions they had. In the print-format condition, we provided users
with two books: that of Bergmann (1953) and Richardson (2004). We showed them how the
contents of each book were organized. Then, we asked them to find certain statutes as quickly as
possible while we tracked the time. For the first three statutes, we provided just the numbers: §4,
§101, and §260. We measured how much time it took for them to open the right pages for both
books. For the next three statutes, we provided just the topics: "theft," "alcohol," and "value of
animals."24 For the final three statutes, we provided just the keywords: "a verdict," "blind eye,"
and "a goat." These keywords were selected because they appear only once for each statute and
could be located by means of the index in the appendix of Richardson's (2004) book. These
operations were then repeated for the PDF format condition; that is, we provided a laptop and
opened the two books in Adobe's PDF viewing application. We also demonstrated how clicking
CTRL+F would allow them to search the entire PDF file for certain words or phrases. In the third
and final condition, we asked users to look up the same statutes while using eHammurabi.com on
a laptop, tablet, and smartphone. That is, they had to navigate to the nine statutes on three
24 In Richardson's (2004) translation, there is an index that groups statutes according to the exact names provided.
EHAMMURABI.COM CASE STUDY 39
Preprint V.2.3.5
separate devices with different screen sizes. The order in which participants were given print
books, PDF files, and the website conditions was modified for every three participants.25
The entire study took about 90 minutes to complete for each participant. If it took a user
more than five minutes to find a statute, we stopped tracking the time and proceeded to the next
one. The compiled results are shown in Table 4, below:
Table 4
Results of Time-Tracking Study for Findings Statutes on eHammurabi.com
Statute groups and numbers
Baseline Formats eHammurabi.com
Print PDF Laptop Tablet Mobile
By number
§4
§101
§260
Average
By topic
Theft (§§6–25)
Alcohol (§§108–111)
Value of animals (§§241–252)
Average
By keyword
'a verdict' (§5)
'blind eye' (§169)
'a goat' (§270)
Average
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
> 5m
1m 17s
1m 28s
1m 36s
1m 27s
1m 48s
2m 3s
2m 20s
2m 4s
1m 33s
1m 45s
1m 26s
1m 35s
5s
9s
7s
7s
7s
11s
14s
11s
9s
11s
7s
9s
7s
12s
10s
10s
12s
15s
18s
15s
13s
14s
10s
12s
7s
12s
11s
10s
11s
16s
21s
16s
10s
11s
6s
9s
Cumulative averages
> 5m 1m 42s 9s 12s 12s
Note. Data compiled by Boban Dedović. The study included nine participants. Its limitations are discussed shortly.
25 Three of the participants were given print books, then PDF files, then the website; the next three were given the
website, then print books, then PDF files; and the final three were given PDF files, then the website, then print
books. This is a simplified version of "randomized block design," which helps reduce a study design's bias.
EHAMMURABI.COM CASE STUDY 40
Preprint V.2.3.5
As expected, locating a single statute in the Law Code of Hammurabi was slowest in the form-
factor of print books. Every participant took over five minutes to complete the task. While the
PDF condition was an improvement over print books, it still required almost ninety seconds on
average to find the right pages for both files. Some users preferred to use the search function
while others preferred scrolling. When using the eHammurabi.com website, these same
operations took an average of eleven seconds. The laptop condition was the fastest form-factor.
3.1.2. Explanation of Internal Results
While the design of this study does have notable limitations and drawbacks,26 two
conclusions seem reasonable: (1) finding a statute is faster when fewer resources are required;
and (2) user interface design is a strong predictor of how long it takes to find a given statute.
First, finding a statute's contents whilst using a single resource is faster in comparison to two.
That is, when users have to use more than one resource–whether print or digital–a duplication of
efforts cannot be avoided. Switching between two resources requires shifting attention, which
takes time. As a result, finding statutes whilst using eHammurabi.com was probably faster
because users did not have to go back-and-forth. This makes a strong case for our argument that
data aggregation is an important aspect of digital tools that treat ancient languages. This finding
is also supported by the fact that existing digital tools take the same approach.
Second, it seems to us reasonable to conclude that user interface design is an important
component of user experience, and of digital tools in general. In the case of eHammurabi.com, a
single-page design and persistent left-side navigation menu were critical design choices. Without
a single-page user interface, we speculate that it would have taken much longer to switch
between tabs, as was the case when participants were given PDF files. Also, because the
eHammurabi.com website isolated the contents of interest for each statute, it was unnecessary for
our testers to scroll through the front matter and footnotes of the original publications. We reason
that the left-side navigation menu on eHammurabi.com was a critical time-saving feature. That
26 The sample size of nine participants was relatively small; and because they were undergraduate students, it is not
a representative sample from a demographic standpoint. The study design was basic in nature, and not double-blind.
Despite these and other limitations, we speculate that the results are replicable. That is, if disinterested investigators
repeated the study according to our described methodology, the findings would probably be comparable.
EHAMMURABI.COM CASE STUDY 41
Preprint V.2.3.5
is, chunking all the statutes into groups and providing links for users to click on reduced the need
for scrolling or searching.
3.1.3. External Reception
External reception of the eHammurabi.com project seems to have been positive. Since
launching the initial version in February 2021, the website's traffic has increased tremendously.27
From April 20 – May 20, 2023, we received 121,510 requests. Roughly 68.7% of these were
from desktop or laptop devices, 30.1% from smartphones, and 2.1% from tablets. Of the 121,510
website requests, 3,140 of them represented unique visitors. This means that once users visit
eHammurabi.com once, they are likely to visit the website again. These recurring visitors are
likely using the digital tool as a reference work.
Other websites and content creators are using eHammurabi.com in order to make the Law
Code of Hammurabi more accessible for an even wider audience. For example, one of the main
sources of incoming traffic is the popular digital encyclopedia known as Wikipedia. Article
editors are actively using the contents of the website on various Wikipedia articles, and
attributing their source to eHammurabi.com. Another user success-story is an author of a
YouTube channel titled "Learn Akkadian." This creator used eHammurabi.com in order to
publish a video that walks users through the translation process of the first statute. We discovered
the creator because he provided a link to the eHammurabi.com website in his video's description.
Because of use-cases like these, we are optimistic that more individuals will be exposed to the
Akkadian language. The same can be said for the other websites that are actively providing a link
back to eHammurabi.com. Furthermore, a modest number of researchers, educators, and students
reached out to us privately. They indicated that they are using the tool as an aid for studying the
Akkadian language. These results suggest that researchers are benefiting from our approach.
3.2. Implications and Future Work
It remains to discuss the present case study's key takeaways, their implications, and the
future of eHammurabi.com. Building a digital tool for ancient languages like Akkadian was
uniquely difficult. Following time-honored best practices like data aggregation, data granularity,
and multi-panel user interface design proved useful. The importance of task-focused user
27 The following data were derived from Cloudflare's analytics tool as well as Google Analytics.
EHAMMURABI.COM CASE STUDY 42
Preprint V.2.3.5
interface design cannot be stressed enough. Because tools like Google Sheets and others allow
for rapid prototyping, future investigators ought to be encouraged to build their own digital tools.
More advanced projects would likely benefit from interdisciplinary cooperation. Moving
forward, the eHammurabi.com project plans to implement rich new features like integration with
the Chicago Assyrian Dictionary. Content additions like the prologue and epilogue of the Law
Code of Hammurabi and multi-translation comparisons are also on the development roadmap.
3.2.1. Recommendations Applicable to Others
Our findings from developing the eHammurabi.com website is significant for both
current and forthcoming practitioners of digital humanities. First, our focus on ancient languages
brought attention to the fact that digital tools in this space have special needs. Second, our review
of existing tools that negotiate said needs found that certain features are both commonplace and
effective. This means that practitioners ought to regard efforts in data aggregation, data
granularity, and multi-panel user interfaces as time-honored best practices–if only as a starting
point for any digital project. Third, our approach of defining an objective, measurable user goal
and proceeding to build a user interface focused on said goal seems to be an important aspect of
the planning phase. Fourth, our findings concerning the importance of user interface design
ought to encourage all existing practitioners to consider the impact it has on their own digital
tools' user experiences. Fifth, our use of free spreadsheet software for rapid prototyping ought to
encourage non-technical practitioners to attempt to create new digital tools on their own.
Finally, our experience suggests that digital humanities projects are best served when
there is strong interdisciplinary cooperation. That is, when practitioners of ancient languages and
computer science work together, the results are more likely to be remarkable. This is because
both disciplines have their share of complexities and unique challenges; consequently, joining
forces as a team is recommended. It may be particularly beneficial for language experts,
developers, and user interface designers to collaborate on a single project.
3.2.2. Future Work on eHammurabi.com
The eHammurabi.com project's development roadmap tentatively includes plans to
integrate dictionary entries, translation comparisons, and inclusion of the prologue and epilogue.
Since joining forces with the OMNIKA Foundation in early 2023, the Electronic Hammurabi
EHAMMURABI.COM CASE STUDY 43
Preprint V.2.3.5
will benefit from additional development resources; and integration with OMNIKA's index of
contents related to world mythology. For example, one of OMNIKA's (2023) projects is Allo, a
modern dictionary platform for dead ancient languages.28 By accessing data from Allo's
forthcoming Akkadian dictionary, eHammurabi.com can serve authoritative definitions derived
from the Chicago Assyrian Dictionary. This single integration will aggregate data from the
twenty-one-volume publication, plus provide grammatical information on individual words and
their forms. Users will likely save even more time by having this feature. The same can be said
of integrating mythology and language data from OMNIKA's core index.
Content additions like translation comparisons will also likely contribute to the utility of
the eHammurabi.com digital tool. Because the website's role is that of a data aggregator, it only
requires additional data entry to expand the number of records for each statute. Thereafter, we
plan on allowing the user to expand a single statute so that they can read and compare multiple
transliterations, normalizations, and English translations. This feature will likely invite more
seasoned practitioners of the Akkadian language to use the tool for research. All this will have to
be done without overloading the user interface with too much information. Finally, the addition
of the prologue and epilogue will hopefully deliver the same time-saving benefits of the current
tool to the entirety of the Law Code of Hammurabi.
3.3. Summary of Case Study
Hitherto we have described how eHammurabi.com was built–from concept to execution–
in order to create a useful digital tool for studying the linguistic contents of the Law Code of
Hammurabi. In the Introduction and Approach section, we first established that Akkadian is a
complex ancient language because of its multi-step translation process, the technicality of certain
required materials, and the need for proprietary information. Following a review of relevant
digital tools, we determined that the best ones shared several common best-practices: data
aggregation, data granularity, and interactive multi-panel user interfaces. The eHammurabi.com
website sought to build upon this. A secondary review of digital tools like iPhone, productivity
software, and Google Search prompted us to establish more precise goals and priorities. The
findings of this review suggested that popular digital tools help users achieve specific tasks better
than others; and that user interface design is a critical component. Thereafter, we posited three
28 The present author was involved in the development of Allo. See Dedović (2023) for more information.
EHAMMURABI.COM CASE STUDY 44
Preprint V.2.3.5
arguments: (1) a robust digital tool must be both an aggregator and redactor of several
authoritative publications; (2) the user interface of said tool is its most important aspect; and (3)
the user interface must be designed in accordance with a singular, pre-determined user goal that
can be quantified and measured objectively. The following strategic workflow was observed:
define the user goal; design the user interface; and measure the quality of the user experience
with respect to the original user goal. Our user goal was to enable users to find a single statute's
contents in the Law Code of Hammurabi as quickly as possible.
In the Development and Execution section, we described how the main features of the
eHammurabi.com website were built, and why they were appropriate for our user goal. The final
user interface contained a persistent left-side navigation menu and four vertical panels within a
single-page website application. The single-page approach meant that all 282 statutes of the Law
Code of Hammurabi were accessible from a single website page. The left-side menu acted as a
mini-index whereby users could click on a statute to see its contents. The four vertical content
panels contained the cuneiform signs, transliteration, normalization, and translation for each.
Five independent, authoritative publications were selected, and their respective data redacted in
order to populate the contents of each panel. The cuneiform signs were mainly derived from
Bergmann (1953), and the remaining contents from Richardson (2004), Huehnergard (2011),
Huehnergard (2013), and Abulhab (2017). We decided to build eHammurabi.com as a website
accessible through a browser because this option proved to be accessible for more users, versatile
for different devices, and easier to maintain. Data were stored in XML file format. The final
version of the website is kindly provided on https://ehammurabi.com.
In the Results and Discussion section, we reported our satisfactory results and discussed
their implications. The final version of the website met our internal goals. A brief study was
conducted to determine if eHammurabi.com enabled users to find a given statute's contents faster
than print books or PDF files on a laptop. We asked nine participants to look up statutes
according to its number, topic, or key word. Our results suggest that eHammurabi.com allows
users to find contents related to the Law Code of Hammurabi an order of magnitude faster than
the other two options. To explain these results, we provided two reasons. First, using a single
website that aggregates data from other publications is faster than using separate print books or
PDF files. Second, certain features of eHammurabi.com's user interface assisted greatly. The
EHAMMURABI.COM CASE STUDY 45
Preprint V.2.3.5
critical features included the left-side navigation menu as well as the single-page design. Our
findings have implications for practitioners of digital humanities. Mainly, complex ancient
languages like Akkadian have special needs with respect to digital tools. Aggregating data from
multiple sources and serving them in a multi-panel user interface helps address these challenges.
Next, task-focused user interface design seems to be worthy of extra attention, owing to its
profound impact on user experience. More work needs to be done to verify the results we
reported. We encourage other investigators to replicate our study's design and methodology.
Interdisciplinary cooperation amongst language experts and computer scientists is recommended.
EHAMMURABI.COM CASE STUDY 46
Preprint V.2.3.5
References
Abulhab, S. D. (2017). The Law Code of Hammurabi: Transliterated and Literally Translated
from its Early Classical Arabic Language. Blautopf.
Allen, J. (2015) Middle Egyptian Literature: Eight Literary Works of the Middle Kingdom.
Cambridge University Press.
Apple Inc. (Jan. 9, 2007). Apple Reinvents the Phone with iPhone.
https://www.apple.com/newsroom/2007/01/09Apple-Reinvents-the-Phone-with-iPhone
Bergmann, E. (1953). Codex Ḫammurabi: Textus Primigenius. Pontificium Institutum Biblicum.
Borger, R. (2004). Mesopotamisches Zeichenlexikon. Ugarit–Verlag.
Cuneiform Digital Library Initiative. (2023). About CDLI. https://cdli.mpiwg-
berlin.mpg.de/about
Dedović, B. (2021). Electronic Hammurabi: A Digital Version of the Law Code of Hammurabi.
OMNIKA Foundation. https://ehammurabi.com
––––. (2023). Allo: A Modern Digital Dictionary Platform for Ancient Languages [Conference
presentation]. 24th Biennial Dictionary Society of North America Conference, Boulder,
CO, United States. https://dictionarysociety.com/conference/dsna-24-in-boulder-colorado
Faithlife, LLC. (2023). Logos Bible Study Platform. https://www.logos.com
Google. (2023). Material Design. https://m3.material.io
Harper, R. F. (1904). The Code of Hammurabi, King of Babylon, about 2250 B.C (2nd ed.).
University of Chicago Press.
Huehnergard, J. (2011). A Grammar of Akkadian (3rd ed.). Eisenbrauns.
Huehnergard, J. (2013). Key to a Grammar of Akkadian (3rd ed.). Eisenbrauns.
Kahane, A., Mueller, M., Berry, C., & Parod, B. (Eds.). (2023). The Chicago Homer.
https://homer.library.northwestern.edu
Labat, R. (1976). Manuel D' Épigraphie Akkadienne: Signes, Syllabaire, Ideogrammes (5th ed.).
P. Geuthner.
Louvre Museum. (2023). Code of Hammurabi [Basalt stele]. Near Eastern Antiquities, Richelieu
wing, Room 227, Louvre Museum, Paris, France.
https://collections.louvre.fr/en/ark:/53355/cl010174436
MS-DOS. (2012). In Wikipedia. https://en.wikipedia.org/wiki/MS-DOS
EHAMMURABI.COM CASE STUDY 47
Preprint V.2.3.5
OMNIKA Foundation. (2023). Allo: A Modern Dictionary Platform for Ancient Languages.
https://allo.conscious.ai
Palma, R., Perry, D., & Lawall G. (2009). Ecce Romani III: A Latin Reading Program (4th Ed.).
Prentice Hall.
Pew Research Center. (Dec. 6, 2022). Social Media Seen as Mostly Good for Democracy Across
Many Nations, But U.S. is a Major Outlier.
https://www.pewresearch.org/global/2022/12/06/internet-smartphone-and-social-media-
use-in-advanced-economies-2022
Porter, D. (2009). Changing the Center of Gravity: Transforming Classical Studies Through
Cyberinfrastructure. Digital Humanities Quarterly, 3(1).
Richardson, M. E. J. (2004). Hammurabi's Laws: Text, Translation and Glossary. T & T Clark
International.
Roth, M. T., & Michalowski, P. (Ed.). (1995). Law Collections from Mesopotamia and Asia
Minor (Vol. 6). Scholars Press.
Roth, M. T., Reiner, E., Oppenheim, A. L., Landsberger, B., et al. (Eds.). (1956–2011). Chicago
Assyrian Dictionary (21 Vols.). Oriental Institute.
––––. (1956). Chicago Assyrian Dictionary / Vol. 6, Ḫ. Oriental Institute.
––––. (1960). Chicago Assyrian Dictionary / Vol. 7, I and J. Oriental Institute.
––––. (1992a). Chicago Assyrian Dictionary / Vol. 17, Part II, Š. Oriental Institute.
––––. (1992b). Chicago Assyrian Dictionary / Vol. 17, Part III, Š. Oriental Institute.
Scaife, R., Crane, G., Beaulieu, M., Almas, B., et al. (2023). Scaife Viewer: Open Greek and
Latin Perseus Digital Library. https://scaife.perseus.org
The University of Pennsylvania. (2017). The Pennsylvania Sumerian Dictionary Project.
http://oracc.museum.upenn.edu/epsd2
Viel, H. D. (2012). The New Complete Code of Hammurabi. University Press of America.
Windows 1.0x. (2015). In Wikipedia. https://en.wikipedia.org/wiki/Windows_1.0x
