2012-12-10 89 views
11

我即將啓動調查的移動應用程序。將有2個用戶:驗船師Survey_Taker。驗船師將設計調查並將其發送給調查員。調查員完成調查並將其發回給驗船師。移動調查應用程序的體系結構

現在,我會需要承載網絡上的數據庫同步從調查接受者的移動的數據發送回surveyor.Or我可以不用呢?

想知道如果我可以用調查數據存儲在一個文本文件的功能發送的調查?那會有什麼後果?

+0

調查者是否也在使用移動應用程序查看結果,或者是應用程序桌面/基於Web的應用程序? – Raul

+0

@Raul驗船師應通過他/她的手機接收並填寫調查表。這些將由調查員發送。 –

回答

3

我會建議一個瘦服務器負責存儲和彙總一些報告數據。具有服務器以在客戶端類型之間進行同步將證明更加健壯。 存儲可以用文件完成,比如說JSON格式。或者,根據擴展需求,存儲可以切換到NoSQL db。 要快速啓動,您可以使用Node.js服務器。

+0

所以你的意思是:「一旦客戶的手機上接收到調查結果並且客戶端填寫完畢後,輸入的值就會以JSON格式存儲在一個平面文件中,然後這些數據被提取到數據庫(NoSQL數據庫)託管在服務器上「。如果我錯了,請確認並糾正我。 –

+1

我想我的觀點是有一個(NoSQL)數據庫是一個可擴展性而不是設計的問題。你可以沒有一個罰款。關於調查的方式以及接受調查者和查看調查者的方法是通過服務器進行的。將調查存儲在服務器上並傳遞給客戶端。測量員應用程序可以輪詢服務器以獲取新結果。希望這可以幫助。 – Raul

+0

對!另一種選擇:我可以設計我的調查接收或發送爲電子郵件正文/附件(HTML5/CSS)? –

4

可以完美地通過電子郵件發送的調查結果給調查沒有做一個數據庫,例如。但是,分析結果可能有點不舒服。因此,您對數據庫的需求主要取決於您的報告要求。所以:你想對數據做什麼?

+0

我想用圖表和圖表來表示數據。 –

4

作爲一個移動應用程序,我肯定會考慮以下特點:

  • 書籤的調查
  • 儲存在我的手機調查中供以後完成
  • 回答調查下線
  • 發送調查到服務器
  • Reconciliate收到的調查(在案件調查中的問題,在此期間已經改變)

這已經說了,我會在移動和服務器上的數據庫使用本地(文件?)存儲。

+0

服務器上的數據庫是否有其他替代品?我可以做出來嗎? –

+0

我不能簡單地使用電子郵件和平面文件嗎? –

+0

我不能在javascript中設計我的調查。然後通過電子郵件正文/附件發送給survey_taker?你能指導我選擇這個選項嗎? –

5

採取調查,另一種方法是使用谷歌表單 http://www.labnol.org/software/google-docs-forms-for-surveys/10056/

確保:

  • 良好的移動設備上瀏覽
  • 發送電子郵件,結果第一
+0

這確實是一種開發調查應用程序的非常經濟的方法。不知道Google文檔是否有助於報告? –

+1

是的,Goolge Forms支持調查分析。 http://www.mattsilverman.com/2008/10/introduction-to-google-forms.html – Raul

0

小問題:

是的,你可以使用文本文件,但我認爲JSON更簡單。當用特殊字符打印,明確和安全時,它是人類可讀的。

你可以有你自己的簡單的RESTful的數據庫,你可以使用一些大型的應用程序的網站(Google網站/ FB /等),你甚至可以發送電子郵件來回,這是給你的。

客戶端你想要HTML5。

但是,系統最重要的方面(*)對於大多數用戶(調查接受者)來說是可用的。

考慮這個可怕的例子:

What is your age: 
[ ] between 1 and 5 
[ ] between 6 and 10 
etc. 

然後考慮這一點,絕對調查的殺手:

How much do you agree with the following: 
          not at all/not really/neutral/somewhat/a lot 
My cat likes red    [ ]  [ ]   [ ]  [ ]  [ ] 
Eggs are better than ham  [ ]  [ ]   [ ]  [ ]  [ ] 
I don't take a bus   [ ]  [ ]   [ ]  [ ]  [ ] 
I hate politics    [ ]  [ ]   [ ]  [ ]  [ ] 
Fish is expensive    [ ]  [ ]   [ ]  [ ]  [ ] 
Pollution is good    [ ]  [ ]   [ ]  [ ]  [ ] 
Manager helped me a lot  [ ]  [ ]   [ ]  [ ]  [ ] 
Repairman was not helpful  [ ]  [ ]   [ ]  [ ]  [ ] 
Supervisor knows his shit  [ ]  [ ]   [ ]  [ ]  [ ] 
Salesmen were friendly  [ ]  [ ]   [ ]  [ ]  [ ] 
Office smells and looks nice [ ]  [ ]   [ ]  [ ]  [ ] 

首先,你的用戶不知所措的選擇,許多放棄

然後有些混淆哪個盒子是指哪個問題

然後有些人不會得到雙重否定「不同意修理工沒有幫助」

最終,完成調查的唯一用戶是那些選擇隨機答案的人和一些有真正強烈感情的人。無論哪種方式,結果都是純粹的垃圾 - 隨機性與誇張混合在一起。

現在考慮一個更好的設計調查interace:

What was your impression? 
[smiley]<====[slider]====>[angry] 

How far do you live from our store? 
[house]<=====[slider]=====>[mountain] 

# slider icon changes as you drag it: 
# house/block/road/highway/city/mountain 

當你的調查是快速的點,你會得到更多的答案。

有一個很好的調查,例如,問題不應該暗示性的(你們有多少就像我們的服務?),問題必須是明確的(我們的新章節是如何?),問題不能太個人化(你孩子什麼時候死了?)等等。關於這個主題的書籍是寫的,但是你不能在你的系統中輕易地實施這個。 (*)我假定選擇參與調查的普通用戶,我打折了用戶被迫參與的情況,例如,學校考試。

+0

這個問題具體是關於什麼應該是移動平臺上調查應用程序的理想架構,而不是典型調查應該如何看起來像!雖然,我確實很看重您對此可用性的反饋。請記住,在任何產品生命週期中,首先出現的問題是「什麼」和「爲什麼」......然後是「如何」! –

+0

如果您能詳細說明答案的前6行,我將非常感激。謝謝 –

+0

考慮像這樣的文本文件格式:'question =「多遠?」選項=「1,2,3」現在想象一些客戶詢問「HYD」還有多遠?「並且最終得出」question =「與」ICT「有多遠?」 ...',你不能再解析了。你將不得不發明你自己的轉義序列等。這就是爲什麼堅持現有的格式,JSON或ini文件更好。 –