2008-11-01 35 views
23

Tôi chắc chắn điều này đã được yêu cầu trước đó, nhưng tôi không thể tìm thấy nó.Ứng dụng dựa trên trình duyệt hoặc ứng dụng GUI độc lập?

Lợi ích/hạn chế của việc sử dụng giao diện dựa trên trình duyệt cho một ứng dụng độc lập so với sử dụng khung giao diện thông thường là gì?

Tôi đang làm việc trên chương trình Python hiện đang triển khai với wxPython cho GUI. Ứng dụng này chỉ đơn giản là các biểu mẫu và hộp thoại nhập người dùng. Tôi đang xem xét việc chuyển sang PyQt vì các tiện ích mà nó có (để mở rộng trong tương lai), sau đó tôi nhận ra rằng tôi có thể chỉ sử dụng một trình duyệt để thực hiện nhiều công việc tương tự.

Ứng dụng hiện không yêu cầu truy cập Internet, mặc dù đó là khả năng trong tương lai. Tôi đã nghĩ đến việc sử dụng Karrigell cho khung công tác web nếu tôi sử dụng trình duyệt.


Sửa Để làm rõ, tính đến ngay bây giờ các ứng dụng sẽ dựa trên trình duyệt, không dựa trên web. Tất cả các thông tin sẽ được lưu trữ cục bộ trên máy khách; không cần thực hiện các cuộc gọi máy chủ và không cần truy cập Internet (có thể đến sau này). Nó chỉ đơn giản là một GUI trình duyệt thay vì một GUI wxPython/PyQt. Hy vọng rằng có ý nghĩa.

+0

Về chỉnh sửa: Chắc chắn bạn mất lợi thế của các ứng dụng dựa trên web thông thường và cũng không mang lại cho bạn lợi ích của ứng dụng GUI thực. –

+0

Bạn có thể giải thích thêm về điều đó không? –

+0

Truy cập Internet có thể sẽ xuất hiện trong tương lai, vì vậy bắt đầu dựa trên web là việc kiểm tra trong tương lai. Ngoài ra, các ứng dụng web dễ tạo và mã GUI tùy chỉnh hơn. – crystalattice

Trả lời

10

Những lợi thế rõ ràng để dựa trên trình duyệt:

  • bạn có thể trình bày các giao diện người dùng như nhau bất kể nền tảng
  • bạn có thể nâng cấp các ứng dụng một cách dễ dàng, và tất cả người dùng có cùng một phiên bản của ứng dụng đang chạy
  • bạn biết môi trường mà ứng dụng của bạn sẽ chạy (phần cứng/hệ điều hành máy chủ) giúp kiểm tra và hỗ trợ dễ dàng hơn so với vô số cấu hình phần cứng/hệ điều hành mà ứng dụng GUI sẽ được cài đặt.

Và đối với GUI dựa trên:

  • một số ứng dụng (ví dụ: chỉnh sửa hình ảnh) cho là làm việc tốt hơn trong một ứng dụng giao diện bản địa
  • không yêu cầu truy cập mạng

Xem thêm nhận xét của tôi về this question:

Cross-pl atform GUIs là một vấn đề lâu đời. Qt, GTK, wxWindows, Java AWT, Java Swing, XUL - tất cả đều bị ảnh hưởng bởi cùng một vấn đề: GUI kết quả không có vẻ bản địa trên mọi nền tảng. Tệ hơn nữa, mọi nền tảng đều có một cái nhìn hơi khác và cảm thấy, vì vậy ngay cả khi bạn bằng cách nào đó có thể nhận được bộ công cụ có nguồn gốc trên mọi nền tảng, bạn phải bằng cách nào đó mã ứng dụng của bạn cảm thấy có nguồn gốc trên mỗi nền tảng.

Nó đi kèm với quyết định: bạn có muốn giảm thiểu nỗ lực phát triển và có giao diện không nhìn và cảm thấy hoàn toàn đúng trên mỗi nền tảng hay bạn muốn tối đa hóa trải nghiệm người dùng? Nếu bạn chọn tùy chọn thứ hai, bạn sẽ cần phát triển một chương trình phụ trợ phổ biến và một giao diện người dùng tùy chỉnh cho mỗi nền tảng. [chỉnh sửa: hoặc sử dụng ứng dụng web.]

Một suy nghĩ khác mà tôi vừa có: bạn cũng cần xem xét loại dữ liệu mà ứng dụng của bạn thao tác và vị trí lưu trữ và cách người dùng cảm nhận về điều đó. Mọi người rõ ràng không quan tâm đến dữ liệu hồ sơ facebook của họ được lưu trữ trên máy chủ web, nhưng họ có thể cảm thấy khác nếu bạn viết một ứng dụng tài chính như MYOB và bạn muốn lưu trữ tất cả chi tiết tài chính cá nhân của họ trên máy chủ của bạn. Bạn có thể có được điều đó để làm việc, nhưng nó sẽ đòi hỏi rất nhiều nỗ lực để thực hiện bảo mật cần thiết và để đảm bảo cho userbase rằng dữ liệu của họ được an toàn. Trong tình huống đó, bạn có thể quyết định rằng nỗ lực tổng thể sẽ thấp hơn nếu bạn sử dụng ứng dụng GUI gốc.

+0

"[chỉnh sửa hình ảnh] được cho là hoạt động tốt hơn trong ứng dụng GUI gốc" ARGUABLY ?! Bạn không thể xử lý ảnh không tầm thường trong trình duyệt .. – dbr

+1

Flickr có chỉnh sửa hình ảnh trong trình duyệt. Nó hoạt động khá tốt. –

+0

Phiên bản dựa trên web của Photoshop khá thú vị, nhưng tôi cho rằng Adobe lừa dối khi thấy 'họ' tạo ra flash. –

0

Trình duyệt có thể được truy cập ở mọi nơi bằng internet và bạn triển khai nó trên máy chủ. Ứng dụng dành cho máy tính để bàn phải được triển khai cho máy tính của họ và mỗi máy tính bằng cách nào đó có tính độc đáo riêng của nó ngay cả với cùng một hệ điều hành và cùng một phiên bản. Điều này có thể mang lại cho bạn rất nhiều phức tạp. Truy cập web.

4

Khi nói đến mục nhập dữ liệu đơn giản sử dụng biểu mẫu nhập người dùng, tôi cho rằng việc sử dụng giải pháp dựa trên trình duyệt có thể dễ dàng và nhanh hơn để phát triển.

Trừ tính năng cốt lõi của bạn là giao diện riêng của mình ("Nếu đó là một chức năng kinh doanh cốt lõi -. Tự mình làm, không có vấn đề gì", xem In Defense of Not-Invented-Here Syndrome từ Joel on Software), tôi cảm thấy rằng trình duyệt sẽ có thể thực hiện biểu mẫu hiển thị và xử lý tốt hơn việc phải phát triển GUI từ đầu. Ngoài ra, không phải đề cập đến nó sẽ mất một thời gian lâu hơn để mã một GUI như trái ngược với việc tạo ra các hình thức HTML và xử lý chúng sau khi chúng được POST bởi trình duyệt.

Điều tôi đã tìm thấy trong quá khứ là tôi được một người bạn yêu cầu viết một ứng dụng để nhập kết quả từ một cuộc khảo sát. Lúc đầu, tôi đã viết một applet Java để hiển thị bản khảo sát với tất cả các hộp radio, khi nó đánh tôi rằng tôi nên viết một máy chủ HTTP đơn giản để tạo ra các biểu mẫu và xử lý chúng.

gì nó thực sự đi xuống là để cho dù bạn đang hoặc đang phát triển:

  1. giao diện người dùng
  2. ứng dụng dữ liệu nhập cảnh

Nếu bạn đang làm một ứng dụng dữ liệu nhập cảnh, sau đó để giao diện người dùng cho trình duyệt và tập trung vào chức năng cốt lõi của bạn.

+0

Đó là một trong những lý do tôi đang xem một trình duyệt; lượng thời gian dành cho GUI so với "logic nghiệp vụ" thực tế. Điểm tốt. – crystalattice

3

Lợi ích của giao diện dựa trên trình duyệt:

  • Dễ quản lý hơn: không cần cài đặt trên máy người dùng, nâng cấp cần chỉ được thực hiện trên phía máy chủ và ngay lập tức có sẵn cho tất cả người dùng. Sao lưu dữ liệu có thể được thực hiện trên một máy đơn vì dữ liệu sẽ không được trải ra trên nhiều máy khách.
  • Ứng dụng có thể được truy cập từ bất kỳ máy nào bằng trình duyệt.
  • Có thể dễ dàng hỗ trợ nhiều nền tảng nhất quán.
  • Yêu cầu về bộ nhớ và CPU có thể ít hơn đáng kể ở phía máy khách vì có thể thực hiện các thao tác chuyên sâu trên máy chủ.
  • Tăng cường bảo mật: dữ liệu được lưu trữ trên một máy chủ duy nhất thay vì nhiều máy khách và quyền truy cập có thể được kiểm soát tốt hơn.
  • Nhiều lợi ích khác của môi trường tập trung bao gồm ghi nhật ký, dữ liệu được nhập từ nhiều nguồn có thể có sẵn ngay lập tức từ các khách hàng khác, v.v.
  • Thường dễ dàng hơn để gỡ lỗi và phát triển các giải pháp dựa trên web dễ dàng hơn.

Lợi ích của giao diện GUI-based:

  • Có thể dễ dàng hơn để thiết kế một giao diện phản ứng nhanh hơn, chất lỏng.
  • Có thể tận dụng chức năng dành riêng cho hệ điều hành có thể không có sẵn thông qua trình duyệt.
  • Không nhất thiết yêu cầu quyền truy cập mạng.
  • Bạn không cần phải lo lắng về các sự cố tương thích với trình duyệt.
  • Không có điểm lỗi nào nếu máy chủ không hoạt động hoặc không hoạt động.
2

Có bằng chứng khá tốt cho thấy vấn đề thẻ trump trong hầu hết các trường hợp là khả năng triển khai và hỗ trợ. Ứng dụng trình duyệt có chi phí thấp hơn nói chung; triển khai và hỗ trợ hơn một vài chục người dùng có thể sẽ phải tiêu thụ tài nguyên hỗ trợ đáng kể.

tôi thấy một bảng một hoặc hai năm trước cho thấy một cái gì đó như:




chất lượng UI - Desktop
Mức độ chi tiết của validation - Desktop
năng đáp ứng - Desktop
tài khoản chấp nhận - Desktop
v.v. - Máy tính để bàn
v.v. - Máy tính để bàn
Cài đặt & Hỗ trợ - Trình duyệt
và Trình duyệt sẽ thắng.

10

Hãy giả vờ trong chốc lát rằng sự phát triển/triển khai/nỗ lực bảo trì/chi phí là bình đẳng và chúng ta nhìn vào nó từ góc độ của người dùng ứng dụng:

nào UI được người dùng sẽ tìm thấy hữu ích hơn?

về

  • Dễ sử dụng
  • năng đáp ứng
  • mẫu
  • Quen thuộc navigation/sử dụng
  • Hầu hết giống như các công cụ/các ứng dụng khác được sử dụng trên nền tảng này (ví dụ, có nguồn gốc)

Tôi hiểu rằng "hữu ích" là chủ quan. Cá nhân tôi sẽ không bao giờ sử dụng (như một người dùng, không phải nhà phát triển) một giao diện web một lần nữa nếu tôi có thể thoát khỏi nó. Tôi ghét chúng.

Có một số ứng dụng không có ý nghĩa để phát triển làm ứng dụng dựa trên trình duyệt.

Từ góc độ phát triển

  • Không có hai trình duyệt hiện nay làm cho chính xác giống nhau.
  • Ngay cả với Ajax, javascript và các giao diện đáp ứng động, không tầm thường để triển khai/gỡ lỗi.

Có rất nhiều, nhiều ứng dụng GUI độc lập chỉ khủng khiếp, không tranh luận. Phát triển/triển khai và bảo trì cho một giao diện đa nền tảng là không tầm thường.

Phát triển giao diện người dùng tốt là khó khăn, thời gian. Thực tế là tôi đã kiếm sống trong 10 năm qua phát triển hầu hết các ứng dụng dựa trên web, vì chúng phát triển nhanh hơn, dễ triển khai và cung cấp đủ tiện ích mà mọi người sẽ sử dụng nếu họ phải làm.

Tôi không tin rằng hầu hết người dùng sẽ sử dụng giao diện web nếu được thay thế.

IMNSHO

2

Đối với tác vụ này (trình nhập văn bản dựa trên biểu mẫu) trình duyệt tuyệt vời. Bạn không cần bất cứ điều gì mà là một ứng dụng máy tính để bàn sẽ cung cấp cho bạn (tốc độ, tính linh hoạt)

Có vẽ-lưng để trở thành một ứng dụng web, chẳng hạn như ..

Đó là một trang web. Có những điều bạn không thể (dễ dàng) làm

Bạn không thể dễ dàng ánh xạ phím ctrl + j để làm điều gì đó. Ví dụ: Bảng tính Google cố gắng ánh xạ phím tắt và hoạt động nhất thời gian, đôi khi trình duyệt xử lý mặc định của phím tắt chiếm hơn ..

Bạn không thể tạo cảnh báo Growl (Khung thông báo OS X). Bạn không thể truy cập hệ thống tập tin. Rất khó cho phép truy cập khi ngoại tuyến.

Javascript rất nặng CPU.

Thử thay đổi kích thước tài liệu Bảng tính Google hoặc tải trang trên Digg (trang web nặng javascript) - mức sử dụng CPU của trình duyệt sẽ ở mức 100% trong một thời gian .. Làm như vậy trong ứng dụng máy tính để bàn gốc là không đáng kể

Khi bạn thực hiện nâng cấp, bạn buộc chúng trên tất cả người dùng của bạn. Với ứng dụng dành cho máy tính để bàn, họ có lựa chọn không nâng cấp. Ví dụ, tôi không thích một trong những nâng cấp của Google Reader, nhưng tôi đã bị mắc kẹt. Sử dụng NetNewsWire (một ứng dụng máy tính để bàn), nếu tôi không thích sự thay đổi trong phiên bản mới nhất, tôi có thể khá dễ dàng tiếp tục sử dụng cái này (hoặc thử nó, và hạ cấp)

Bạn web-server phải được có thể truy cập mọi lúc, cho từng số

Nếu máy chủ biến mất, người dùng của bạn không thể truy đòi. Ứng dụng đã biến mất. Nếu nó xuống trong 10 phút, họ không thể sử dụng nó.


Với ứng dụng của bạn, trong khi tôi không chắc chắn nó là gì, không có điều nào ở trên dường như là vấn đề.

"Đó là một -page web": Các hình thức và hộp thoại rất dễ làm trong HTML và javascript (hoặc thậm chí sử dụng server-side scripting, ví dụ <?php if($_POST["email"] ==""){echo("Are you sure you want to continue?); ?>)

"javascript là rất CPU- nặng ": Có vẻ như ứng dụng của bạn sẽ yêu cầu bất kỳ Javascript nào (có thể một số xác thực đầu vào phía máy khách khi người dùng nhấp vào" Gửi ", để cảnh báo cho họ về mọi lỗi nhập?)

" Nâng cấp bắt buộc ": Tôi tưởng tượng điều này có thể được mong muốn, vì bạn không muốn người dùng nhập dữ liệu theo cách cũ.

"Máy chủ phải truy cập được": Có thể là một vấn đề, nhưng tôi không nghĩ nó sẽ là vấn đề lớn ... Giả sử bạn muốn lưu trữ tất cả dữ liệu người dùng trong cơ sở dữ liệu trung tâm, vấn đề này sẽ trở thành không thể tránh khỏi - giữ cho một trang web và máy chủ cơ sở dữ liệu chạy không hoạt động nhiều hơn chỉ một cơ sở dữ liệu (cho GUIs để kết nối)

Ngoài ra, bạn sẽ nhận được những lợi ích mà người khác đã đăng - bạn phát triển nó một lần và nó chạy giống nhau trên mọi hệ điều hành có thể chạy trình duyệt thông minh.

0

Mọi thứ đều có ưu điểm và disavantages, nhưng:

tôi vẫn chưa sử dụng một ứng dụng dựa trên trình duyệt duy nhất trên localhost, mạng nội bộ, hoặc internet mà cảm thấy thoải mái để sử dụng, là đáp ứng, và ai là giao diện người dùng isn' t bị giới hạn bởi các hạn chế của HTML/JS/CSS.

Lưu ý: Giao diện người dùng dựa trên Flash/Java là ngoại lệ (nhưng điều này thậm chí còn tồi tệ hơn và tôi không nghĩ đó thực sự là những gì bạn đang nói ở đây).

1

Một trong những điều tôi ghét về giao diện người dùng dựa trên web là thực tế là chúng chạy bên trong một cửa sổ khác. Có nghĩa là, bạn có quyền kiểm soát - có thể là hàng chục người trong số họ - không liên quan gì đến ứng dụng của bạn. Từ một điểm khả năng sử dụng, điều này có thể gây nhầm lẫn mặc dù hầu hết chúng ta đã thích nghi bằng cách "điều chỉnh" những thứ bổ sung.

Khi tôi nhìn vào cửa sổ trình duyệt của mình khi tôi nhập cửa sổ này, cửa sổ có thể cao 12 inch, nhưng cửa sổ mà tôi nhập chỉ có thể là 3 inch. Và trong tổng số 12 inch đó, có lẽ hai inch đầy đủ được đưa lên với thanh công cụ trình duyệt, tab, hàng dấu trang và thanh trạng thái, không cái nào trong số đó có liên quan đến ứng dụng web mà tôi đang tương tác. Có rất nhiều không gian lãng phí (cửa sổ chỉnh sửa không rộng bằng toàn bộ cửa sổ, ví dụ), không gian chứa đầy những thứ tôi không cần, vv Một số điều khiển cơ bản nhất (nút quay lại, tôi ' m nhìn bạn) hoàn toàn có thể phá vỡ các ứng dụng web được thiết kế kém.

Chưa kể một thực tế là nếu tôi gõ một phản ứng đủ dài tôi bây giờ kết thúc với hai bộ thanh cuộn. stackoverflow.com giải quyết một phần bằng cách cho tôi vùng văn bản có thể thay đổi kích cỡ nhưng tôi vẫn phải tương tác với thanh cuộn bên trong để cuộn văn bản tôi đang chỉnh sửa, sau đó cuộn toàn bộ cửa sổ lên hoặc xuống để truy cập vào các điều khiển ứng dụng ở trên cùng hoặc dưới cùng của cửa sổ chỉnh sửa.

Tất cả trong tất cả, một ứng dụng dựa trên web không thể so sánh với khả năng sử dụng của ứng dụng dành cho máy tính để bàn. Đối với tôi, sau đó, câu hỏi đơn giản trở thành "bạn có quan tâm nhiều hơn đến khả năng sử dụng hay làm cho cuộc sống của bạn trở nên dễ dàng hơn".

Nếu bạn muốn sử dụng, hãy sử dụng ứng dụng dành cho máy tính để bàn. Nếu bạn quan tâm đến việc triển khai và hỗ trợ ứng dụng web thì cần xem xét, nhưng vẫn còn nhiều cách dễ dàng để triển khai ứng dụng dành cho máy tính để bàn, bao gồm việc tạo ứng dụng có thể tự cập nhật trên mạng khi chạy.

0

Tôi nghĩ khái niệm giao diện người dùng dựa trên trình duyệt là ở đây để ở. Không có gì có nhiều thông tin hơn so với bản thân trang web, và chừng nào người ta vẫn ở trong ranh giới của các thư viện javascript phong nha ... việc dựng hình sẽ gần như giống nhau. Thêm vào đó, việc dựng hình không phải là đau đầu của bạn, bạn có thể quan tâm nhiều hơn đến việc tự phát triển logic nghiệp vụ.

tôi tất cả cho nó ...

0

GUI khách hàng giàu có thường sẽ nhanh hơn và tốt hơn tích hợp với giao diện người dùng sẽ được quen với việc đối phó với - điều này không chỉ có nghĩa là chuông và còi, nhưng cũng có nghĩa là rất nhiều tính năng tiết kiệm thời gian như phím tắt.

Giao diện người dùng dựa trên web sẽ di động hơn vì không bị ràng buộc phát triển thành một nền tảng duy nhất và nếu ứng dụng chạy ở xa thì dễ cập nhật hơn và kiểm tra tất cả (ngoại trừ GUI ...) một môi trường nhất quán (máy chủ của bạn). Nhưng bạn nên hiểu rằng trong khi tất cả điều đó là tuyệt vời và thực sự đột phá, nó cũng đi kèm với một số hạn chế nghiêm trọng. Bạn không nên gỡ lỗi ứng dụng dưới tất cả các hệ thống đích, mà còn theo từng trình duyệt duy nhất chạy trên từng hệ thống đích duy nhất ... và đừng quên nhiều phiên bản của cùng một trình duyệt có thể cùng tồn tại trong một thời gian cài đặt có thể sẽ chạy các tập hợp khác nhau (và phiên bản) của các plugin phổ biến khiến ứng dụng hoạt động khác nhau và có thể cài đặt mạng sẽ được tùy chỉnh bởi người dùng. Nếu ứng dụng ở xa nó sẽ mở ra nhiều vấn đề mới thú vị, bắt đầu từ các ISP khác nhau sẽ làm giảm các vấn đề khác nhau ở giữa, hoặc các dịch vụ bị ngừng do sự cố mạng của máy chủ, máy của người dùng hoặc bất cứ nơi nào ở giữa. Ứng dụng từ xa không phải là tùy chọn cho tất cả người dùng ở các quốc gia nơi dịch vụ mạng có chất lượng thấp hoặc không được định giá hợp lý; điều này cũng đúng với bạn: bạn chỉ có thể bắt đầu cung cấp một dịch vụ như vậy nếu băng thông quốc gia của bạn là hợp lý và có giá hợp lý. Và nếu ứng dụng phải làm điều gì đó không tiện lợi trên hệ thống của người dùng, bạn sẽ có thể phải chịu số phận trong việc tạo ra nhiều mã phụ thuộc nền tảng.

Như dòng dưới cùng, hôm nay có những ưu điểm và nhược điểm trong bất kỳ giải pháp nào trong hai giải pháp. Có một số ứng dụng thực sự cần được phát triển theo mô hình khách hàng phong phú và có những ứng dụng thực sự cần được phát triển theo mô hình dựa trên web. Thật tốt khi có cả hai tùy chọn, điều quan trọng là phải có ý tưởng rõ ràng về cách thức phù hợp nhất với chiến lược phát triển/triển khai/hỗ trợ của chúng tôi và tôi có thể thêm vào. nó là viên đạn bạc cuối cùng theo thời điểm của thời điểm này.

0

Giải pháp của tôi là thế này

  1. ứng dụng trang web rõ ràng là đi trên các trình duyệt
  2. các ứng dụng nối mạng mà không cần phải truy cập vào máy tính của khách hàng trôi qua trình duyệt
  3. Bất kỳ ứng dụng mà cần phải được truy cập bởi nhiều hơn một khách hàng tại một thời điểm theo trình duyệt
  4. Ứng dụng sẽ được sử dụng cho mỗi khách hàng mà không cần phải ở lại mạng với gui và điều này có thể bao gồm phần mềm cần nhiều bảo mật khi sử dụng. mặc dù).

Đây là điều gì đó đã học qua một cách khó khăn. Một lý do chính cho việc này là khách hàng thấy dễ dàng cài đặt và quản lý các ứng dụng dựa trên trình duyệt dễ dàng hơn nhiều so với gui, ví dụ: khi sử dụng JavaWebStart nghĩa là máy khách sẽ cần có JRE tối thiểu và số lượt thích của họ trong khi trình duyệt chỉ cần một liên kết.

Trong tất cả các quyết định thực sự là của bạn !. Là một nhà phát triển Java sử dụng JavaFX và Swing có thể giải quyết vấn đề của tôi với vấn đề này.

Các vấn đề liên quan