Trimming.

Geoffrey Challen
1 parent c46c0622
Showing 5 changed files with 25 additions and 32 deletions
conclusion.tex
metric.tex
paper.tex
results.tex
usage.tex
@@ -21,4 +21,4 @@ awards
 \href{http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=1205656}{1205656}
 and
 \href{http://www.nsf.gov/awardsearch/showAward.do?AwardNumber=1423215}{1423215}.
-
+The authors thank the anonymous reviewers for their feedback.
@@ -17,10 +17,10 @@ user is paying attention to. Number of starts is also a potentially-useful
 input, as may be the distribution of interaction times across all times that
 the app was brought to the foreground.
-While these measures of contact time are intuitive, there are obvious cases
+\sloppypar{While these measures of contact time are intuitive, there are obvious cases
 in which they fail, particularly for apps that spend a great deal of time
 running in the background in order to deliver a small amount of useful
-foreground information---such as a pedometer app.
+foreground information---such as a pedometer app.}
 \subsection{User Interface Statistics}
@@ -28,23 +28,23 @@ Patterns of interaction may also be useful to observe, and inputs such as
 keystrokes and touchscreen events are simple to track. However, there is more
 obvious differentiation between app interaction patterns between
 categories---users deliver far more keystrokes to a chat client than to a
-video player---so it is clear that interaction statistics will have to be
-used in conjunction with complementary value measure components that offset
-the differences between high-interaction and low-interaction apps. This
-approach also fails in the case where apps deploy confusing or unnecessary
-interfaces that require a great deal of unnecessary interaction to accomplish
-simple tasks. Clearly such apps should not be rewarded.
+video player---so interaction statistics will have to be used in conjunction
+with complementary value measure components that offset the differences
+between high-interaction and low-interaction apps. This approach also fails
+in the case where apps deploy confusing or unnecessary interfaces that
+require a great deal of unnecessary interaction to accomplish simple tasks.
+Clearly such apps should not be rewarded.
 \subsection{Notification Click-Through Rates}
 Another interesting statistic that could provide insight on app value is how
 often users view or click through app notifications. When notifications are
 delivered but not viewed, then it is unclear whether the app needed to
-deliver them at all. When clickable notifications---such as those for new
+deliver them. When clickable notifications---such as those for new
 email---provide a way for users to immediately launch the app, the percentage
-of notifications that are actually clicked as opposed to ignored could be
-used to at least evaluate how effective the notifications are, and may also
-reflect on overall app value.
+of notifications that are clicked versus ignored could be used to at least
+evaluate how effective the notifications are, and may also reflect on overall
+app value.
 Notification view and click-through rates also help put into context the
 energy used by apps when they are running in the background. Legitimate
@@ -75,8 +75,8 @@ previously considered can fit into this framework:
 \item \textbf{Chat client:} the content is the messages exchanged by users,
 and efficiency is determined by the amount of screen time and interaction
 required to retrieve and render incoming messages and generate outgoing
-messages as replies. Value is measured by the content of the messages and
-efficient chat clients send and receive a large number of messages per joule.
+messages as replies. Value is measured by the content of the messages.
+Efficient chat clients exchange many messages per joule.
 \item \textbf{Video player:} the content is the video delivered to the user
 and efficiency is determined by the amount of network bandwidth and processing
@@ -77,7 +77,6 @@ Apps}
 \input{usage.tex}
 \input{metric.tex}
 \input{results.tex}
-%\input{related.tex}
 \input{conclusion.tex}
@@ -39,6 +39,8 @@ it through a survey completed by 47~experiment participants. Unfortunately,
 our results are inconclusive and open to several possible interpretations
 which we discuss.
+\newpage
+
 \subsection{Total Energy}
 \input{./figures/tables/tableALL.tex}
@@ -115,7 +117,7 @@ redraws.
 \centering
 \includegraphics[width=\textwidth]{./figures/survey.pdf}
-\caption{\textbf{Survey Results.} The height of each bar demonstrates how
+\caption{\small \textbf{Survey Results.} The height of each bar demonstrates how
 many of the suggested apps the user is willing to remove for better battery
 life, with suggestions based on overall usage or our new content-delivery
 efficiency measure. Our new measure does not convincingly out-perform the
@@ -82,17 +82,13 @@ different app features or app configurations used by Alice and Bob.
 By computing value and, thus, energy efficiency, we can overcome these
 weaknesses. A value measure should allow us to compare the efficiency of two
 apps in different categories based on how efficiently they use energy to
-deliver user value.
-%, making it possible to compare games to email clients to video players. 
-Comparisons within the same app category should allow users to
-select the most efficient email client or web browser. Aggregating results
-over all users, differences in app energy efficiency should reflect how well
-the app is written and how well it predicts and adapts to users, not just
-differences in the core features it provides. When comparing two users using
-the same app, differences in efficiency should reflect differences in
+deliver user value. Comparisons within the same app category should allow
+users to select the most efficient email client or web browser. Aggregating
+results over all users, differences in app energy efficiency should reflect
+how well the app is written and how well it predicts and adapts to users, not
+just differences in the core features it provides. When comparing two users
+using the same app, differences in efficiency should reflect differences in
 app configurations or app features.
-%different app configurations or differences in how efficiently the app provides certain
-%features.
 \subsection{Evaluating App Changes}
@@ -101,11 +97,7 @@ and deliver more value per joule. Today&#39;s energy profiling tools may be able
 to show the energy impact of adding a new feature or changing the way that a
 particular feature is implemented, but energy consumption alone is not
 sufficient to apply Amdahl's Law properly to the problem of improving app
-energy efficiency. 
-%For example, if a particular feature consumes a great deal
-%of energy but adds little value, it is possible that it should be eliminated,
-%not improved. Overall 
-Developers should strive to make the parts of their app
+energy efficiency. Developers should strive to make the parts of their app
 that generate a large amount of value as energy-efficient as possible, remove
 parts that generate little value while consuming a great deal of energy, and
 defer work on everything else.